From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 311C3C46CD4 for ; Wed, 27 Dec 2023 01:08:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C00A36B0081; Tue, 26 Dec 2023 20:08:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BB0946B0082; Tue, 26 Dec 2023 20:08:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A50E06B0083; Tue, 26 Dec 2023 20:08:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 971F36B0081 for ; Tue, 26 Dec 2023 20:08:10 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 62D431A048C for ; Wed, 27 Dec 2023 01:08:10 +0000 (UTC) X-FDA: 81610811940.16.3EB72D2 Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by imf18.hostedemail.com (Postfix) with ESMTP id AA39D1C0014 for ; Wed, 27 Dec 2023 01:08:07 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jrgrJOEY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.167.173 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703639287; a=rsa-sha256; cv=none; b=6Ja4707+p+NyS/xom12QHP0H9E7EHnx4CGAwwHMyHEcgBwCu7tO2NxzOPl6h3gCqx8un4y /nC396mA/3EMyNpKFihIwxOZ9vkIbKjBF3wSbc5kK6wXw6vWNxA975rB1P32QEUKqjGZiC I1DzODygimz8gRpoYu63o05PjE1W1NA= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jrgrJOEY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.167.173 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703639287; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rROhmyxFNFY7uwltfCX9hQfXxlOKdfJFBvpyElFG1hs=; b=zmr4O6GvxGU8ZNUjZMaLRzib4I3ku0HtEPSTccWoDM+W1yIFyHZlIHO8qAhrvfJBOAmAGi C4+eyM3r6vY3lD4RatgVjjatW+SpIBY1qieICOJhQPl6sl0eXrfOIzHNlmuxSZWXKqEoBq VNtxuUhP2ODLuvLhFt+FjuZa0m6F7iA= Received: by mail-oi1-f173.google.com with SMTP id 5614622812f47-3bb53e20a43so3802787b6e.1 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=kvack.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=jrgrJOEYs56snpw6Rvy/Z3JKIj8LZYmygir5X940mTuyfbbkRFUr5WYys0hL04Io4W D7sk1Py9fIJWdfuRjCYykFbJdkG9iwavm+de1+2/jDDr5eqWnje570KFquOOY51noNrm zF6FCWmmf9s3HdB8KyWwYi8O08q05dgFRUk/te2xB5Bs+nH5nXr8VQcqRlFF46wEwius QVWp/21/uOTO+1cjN4qwCbUMV1d5SiBmkBSOVllnERVqbBdCbL2RUdb6q0LWxkOWeJC5 qegwQQj96jCtw0cKyejJbMrgpYOoHLToGkqhFbq9vV58dCsydgoTEigVvsooxjgWRbnT vcMw== 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=V/dpVZqEXKIqbDCbV3gfGO0RvHoMcPrZREHE8SkwZMeMwywsPfVmeQl4oMm2X8b3II ddkolTV2PPQh4H/1snkcrWJUvm6RIkvpC+mn6Vi/40ZKvyhABtgqF8Xhvif3zuBT16sa lM2Ctl1eB0TmUHytNFTo8ya0vzB6KCl8DAleKJ13s7GvlkG14557/GuaThwVPprX9tDc mPX7OkA9liE7MV0DdzXllvx+OOnnW9Xv/Ix/psn9yMq2i1Thv7bGuCMRYrRu+g0eT3gq X1IoOCi5QKB65xuu7xfoCecpswOIx2wKOTJiOV48c2XnEvI8vlTM27GkI6vr6Cy+7XMR ZbLQ== X-Gm-Message-State: AOJu0YzAcEFpha+HZedJvLX4M0raIjMSugE0uIfoUQ3vFR6tvJOstrd6 6Zmn2VRTWOMaM8ErfdQiP8yHTHBB0kKYSyk+gSs= X-Google-Smtp-Source: AGHT+IH98XWg68hZrLmLsj6FoDUWpXaSJEpSHkOMw/Hx+Yu4o6TkhC7RrpX9sXFRxc+FsVbzVI5qEuP46zjUCLB9gus= 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) 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 X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: AA39D1C0014 X-Stat-Signature: b9tgfud1qn8rrua459piue6bsbndbk95 X-HE-Tag: 1703639287-180050 X-HE-Meta: U2FsdGVkX18bJwRvmGoS5ntqJiu3/CfWDHmaqBvoZsZWLBN3srdXsFKVnZHrnTprNq8blsOrSb4YThIFaBnK1l6qpafJt6QUPOVqf5rTUu0e8jfWlqotHL5Re07zYyYzBTyH34MJZ0KsMRpzJn5+1SphJcWMUCmvqAOx0X5t9TK6FskyCVwruhSIBTEymGv73sVz7mWeEylNVTe203KAh2YKwAdSsREDCztf2UFN2bxLeZZQOZR2XZbe54upULOWkKtjvnaX/WdzwA5SXirUymhhYtkSuieEF1kBvQSQGsokdR0eLfC8poXz+nw3uDrtEyd63RMtG5sNVemybCUKftBQtC6JVb1/2Cyf/jf3vcK5mQDNxjt72egHquEjYzPz4Z52nKHBFcy7vhvEknKbDOPLPknJZ0m9eGntnXIEEiN8XtdfQXg7qvqjO+e+JAjE9oh5zvd9nlWLjmmr60n1Mj9aCEF64TX1JSEzRJphPVMLTYY0bilQBGav06eJEWLA7LtX5UGZ95FLGsLmG5WCnQUpzHsDxZ/rfnX9Au3qSEjEDZ+VQfdFEhDodp2m6ZhvVY/JBYGogfY2Vw4hTlmHvVdfMieCw1eTvd20zsAFITLS/cwnGoC5OD93TakgatZp0jPsSdYe9P1W92/6zxbhV9RFEIF5ZHd2hjSW3me1dWEUlrkUecpGnVN6Nh4a3wsPMVbgNkk26BOVjVCvy92gzByNaUafj9YtqatWKMuy189jpLareK8j7MqjP+6fKe//srgZQyfojS8XJ3h0DRp002C0X5c8R7tfrpx0+ZxXY0qGAnX9U6Y2ve1dHQ1f+86xdovPvVHEPFW3yNP0+iSxsaAjQH0Yzpm7ExFtCLCw6sOI7FqkEMJLq+hSc+5gGeApnIxULm22eTNde4iZvxhfFPFjjzufWAugDGTpraDK6j8UHDE9GRUxvExlHS/Gq5Sp5GyQajLTBRQSjESeO4e 7P0NNqj+ 17C/cJgF+bwnI3G0iZ9IeRWCEtMDvzFRztC1mgBOsAXdJva8x6hjlUfDUJZDUTF8hzwj8K//wiC5NEebpLx1+q7bHCf4Z2disT/DC+3ij/Sqg+TvHrn5H0eBOe3QHkn55woWaFiKgklG79pT3sSyq2cq290ZpfAu9IkgGG6WRBlBJx9B7/G7m1pEZKU+zVvokTlWmHE3KPVhISAB11ZfztTtrBtL3ms/bMRovMtlYNcplwaNstq6y1XludWxPf7/+LF1qP7RyW+5q9Js1EbggtcHn28jr5PjEmuzXdO79Pip1f8zwr9EPMashR/l7fuom+WHhzhtU7YD0pdNN5bWuQ33dejUr0Om/liclp7wBZ4Ar1GcdbFyH5NcebofcTXpjwgKypV7SNObucY0vCTsjjVqA7Ulp+hBclAHFZjPmlrAyLWLcdT1znuXEwPwZLa2V7OJTyHm/YdnII5AvBwr+nBzH3BlohQdPd+ApIItxv0y9A4ZLlsyNk6/2WqFcXn5L/c4pNMWM7UGjd3Y= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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