Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp3112346rdb; Tue, 26 Dec 2023 17:08:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IF17mjmzP0DtKjTg5rgjx+qC9poHnO1FANn0B1GeDOVR5S4oFFyUG7S2K1Qj3+l693HJUZi X-Received: by 2002:a17:907:7ea1:b0:a26:faa0:96da with SMTP id qb33-20020a1709077ea100b00a26faa096damr968951ejc.108.1703639315469; Tue, 26 Dec 2023 17:08:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703639315; cv=none; d=google.com; s=arc-20160816; b=xmodHXaI7sH7DpNX85DlqEk2tYsbWL5IyqgV0eUyQQnMcWqhC8HWAOSZjdlgfsd/sD IX6eWB3jtoTwmp+oGIMWa1olZmXA97i8qmqqUx6khreKZt6uDbCp1DuSDe3rVOBsDB69 zkOobTgcQ7MLJyoNEcbOG/Y6Bl1BjGp5A7oPKFmS8VTdAooaAAuTHO9Rg6MiHWqw6Gac fP8y9T6fZ2CUq5jkt5DZnKeaHbnlv+jgOKLg5QG0cxKLGg21iRwE6k/JPYNraw7b8HLW ep8sV/4NcjZK7QhjHuigUChLkOl6pLEr0LZhryRbRTFNhq8/Qb4lG0R+vfCtZFBbqeGw P0Mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:dkim-signature; bh=rROhmyxFNFY7uwltfCX9hQfXxlOKdfJFBvpyElFG1hs=; fh=5SgVNP6gviwbhjAC2dSXqt9GMdkNAryZEnhrEUPy3qw=; b=ztMjtRqa4CR4PPaeGDvKIpEEQxQ13AvDwm5WS78bBTKzTR3zlq/Ok1D/3KoiLXYeZ8 mh8GNJ22czYSzz6RVukAEz8xnsO3gvpxlkoVhntJtAM7OPTFgsL/DRmpX9cLu8k9IVcH YWcc9xNfsCMg/zdh02yo+NIwvP6Q2VmVpNjMl2kLN31U4Sd8Rsby5BHLdI4hBzwb3rdH ZL/OjwMRhDm4pVvM5Tu/BsB16duspAGs5GBbZaMXJ+7pfy6pDt6O8HnLF9oEiLRy796z RBR6FPXqKxY1QuaMA60TI7MotfV27cp34hU/2KEFVENw1NMrtqYYpntV26VTk05z696W 3e0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=KEGMr6kD; spf=pass (google.com: domain of linux-kernel+bounces-11748-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-11748-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id f22-20020a170906c09600b00a26ae437f48si5087769ejz.163.2023.12.26.17.08.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Dec 2023 17:08:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-11748-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=KEGMr6kD; spf=pass (google.com: domain of linux-kernel+bounces-11748-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-11748-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 07A0A1F228DE for ; Wed, 27 Dec 2023 01:08:35 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0083B3D7A; Wed, 27 Dec 2023 01:08:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KEGMr6kD" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C48A73C15 for ; Wed, 27 Dec 2023 01:08:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-f176.google.com with SMTP id 5614622812f47-3b9d8bfe845so3803382b6e.0 for ; Tue, 26 Dec 2023 17:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703639287; x=1704244087; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rROhmyxFNFY7uwltfCX9hQfXxlOKdfJFBvpyElFG1hs=; b=KEGMr6kDOsmwIYAiSH3/5p9g3xtc1TEGfi9GWguatLB/bFuIr3dD8wA4vTmUih4qei iZlBCoqgqiXnk3nUxG6QeQdnxz9xIzXGcv6MEfWGAUFPSpji+6807C3I3MVArPvcIz2f DlWBXCptegAO/YhtPCqXTDqC3zEopBa8EIp6fZ6R9OnHxiFfK6CfQclzzytJBw6p4UEw Vlq9/KBAe1vrQdU+ustBNW91i8FImp08fJJaIFYoHdB/rzOvATuETBTKsmC5/jMVBv42 Xs0yFSZt6YqUUbKseaL+NKRPgHIeRm34Oe5A56nAQIXL3C9gTOf0sfRQuWHKPW160HMm dGiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703639287; x=1704244087; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rROhmyxFNFY7uwltfCX9hQfXxlOKdfJFBvpyElFG1hs=; b=Qu72YQoKarXm9Ugn90cHLm5cqzXX4O43jpvN3ZRUAuzLjA2GAaPpuuMJC8Pmto5qda vxhQQheOO15hpQeRLqC3/PJTVyY6cZPqZ4SqnZBEQ86boXDNTH4skyqbNISuD9Ce4KZK CZ4qkTFl8glEgJEXQ5ag4YApWGwtekczNWPm2+1Y5pNH9c/kUgOjMnyigxi6MV020Y1R Bje5t+AoExE8C4GVObzb/GYLvF73QPFt1dnFoS4Ndz5gnHAK21/JYOQ5bfx5jJD+EgCP vZm+mAvXCrkOSIjI4JLG9kKykB25zWpkqiOhgxIprwdkot5ANQwevGzY4t/xNbn/aG1X FbPg== X-Gm-Message-State: AOJu0YwWH2RQEWfedB/UQsdflF7QmGYnd4BUYhbvZal84PSlrz/0+743 H2ACPxKbgJwueMlKPrcJsYilKaIB0z4+u0q3zs4= X-Received: by 2002:a05:6808:1597:b0:3bb:83cd:9f78 with SMTP id t23-20020a056808159700b003bb83cd9f78mr9588395oiw.26.1703639286803; Tue, 26 Dec 2023 17:08:06 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20231213-zswap-dstmem-v4-0-f228b059dd89@bytedance.com> <20231213-zswap-dstmem-v4-1-f228b059dd89@bytedance.com> In-Reply-To: <20231213-zswap-dstmem-v4-1-f228b059dd89@bytedance.com> From: Barry Song <21cnbao@gmail.com> Date: Wed, 27 Dec 2023 14:07:55 +1300 Message-ID: Subject: Re: [PATCH v4 1/6] mm/zswap: change dstmem size to one page To: Chengming Zhou Cc: Andrew Morton , Seth Jennings , Johannes Weiner , Vitaly Wool , Nhat Pham , Chris Li , Yosry Ahmed , Dan Streetman , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Chris Li Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 27, 2023 at 4:55=E2=80=AFAM Chengming Zhou wrote: > > Change the dstmem size from 2 * PAGE_SIZE to only one page since > we only need at most one page when compress, and the "dlen" is also > PAGE_SIZE in acomp_request_set_params(). If the output size > PAGE_SIZE > we don't wanna store the output in zswap anyway. > > So change it to one page, and delete the stale comment. > > There is no any history about the reason why we needed 2 pages, it has > been 2 * PAGE_SIZE since the time zswap was first merged. i remember there was an over-compression case, that means the compressed data can be bigger than the source data. the similar thing is also done in = zram drivers/block/zram/zcomp.c int zcomp_compress(struct zcomp_strm *zstrm, const void *src, unsigned int *dst_len) { /* * Our dst memory (zstrm->buffer) is always `2 * PAGE_SIZE' sized * because sometimes we can endup having a bigger compressed data * due to various reasons: for example compression algorithms tend * to add some padding to the compressed buffer. Speaking of paddin= g, * comp algorithm `842' pads the compressed length to multiple of 8 * and returns -ENOSP when the dst memory is not big enough, which * is not something that ZRAM wants to see. We can handle the * `compressed_size > PAGE_SIZE' case easily in ZRAM, but when we * receive -ERRNO from the compressing backend we can't help it * anymore. To make `842' happy we need to tell the exact size of * the dst buffer, zram_drv will take care of the fact that * compressed buffer is too big. */ *dst_len =3D PAGE_SIZE * 2; return crypto_comp_compress(zstrm->tfm, src, PAGE_SIZE, zstrm->buffer, dst_len); } > > According to Yosry and Nhat, one potential reason is that we used to > store a zswap header containing the swap entry in the compressed page > for writeback purposes, but we don't do that anymore. > > This patch works good in kernel build testing even when the input data > doesn't compress at all (i.e. dlen =3D=3D PAGE_SIZE), which we can see > from the bpftrace tool: > > bpftrace -e 'k:zpool_malloc {@[(uint32)arg1=3D=3D4096]=3Dcount()}' > @[1]: 2 > @[0]: 12011430 > > Reviewed-by: Yosry Ahmed > Reviewed-by: Nhat Pham > Acked-by: Chris Li (Google) > Signed-off-by: Chengming Zhou > --- > mm/zswap.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/mm/zswap.c b/mm/zswap.c > index 7ee54a3d8281..976f278aa507 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -707,7 +707,7 @@ static int zswap_dstmem_prepare(unsigned int cpu) > struct mutex *mutex; > u8 *dst; > > - dst =3D kmalloc_node(PAGE_SIZE * 2, GFP_KERNEL, cpu_to_node(cpu))= ; > + dst =3D kmalloc_node(PAGE_SIZE, GFP_KERNEL, cpu_to_node(cpu)); > if (!dst) > return -ENOMEM; > > @@ -1662,8 +1662,7 @@ bool zswap_store(struct folio *folio) > sg_init_table(&input, 1); > sg_set_page(&input, page, PAGE_SIZE, 0); > > - /* zswap_dstmem is of size (PAGE_SIZE * 2). Reflect same in sg_li= st */ > - sg_init_one(&output, dst, PAGE_SIZE * 2); > + sg_init_one(&output, dst, PAGE_SIZE); > acomp_request_set_params(acomp_ctx->req, &input, &output, PAGE_SI= ZE, dlen); > /* > * it maybe looks a little bit silly that we send an asynchronous= request, > > -- > b4 0.10.1 > Thanks Barry