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 4EAC2C021B2 for ; Sat, 22 Feb 2025 06:26:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A8506B007B; Sat, 22 Feb 2025 01:26:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5312F6B0083; Sat, 22 Feb 2025 01:26:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3AB0E6B0085; Sat, 22 Feb 2025 01:26:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 199386B007B for ; Sat, 22 Feb 2025 01:26:58 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 92E841A070A for ; Sat, 22 Feb 2025 06:26:57 +0000 (UTC) X-FDA: 83146597674.10.5CB58E5 Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) by imf20.hostedemail.com (Postfix) with ESMTP id B16F61C0013 for ; Sat, 22 Feb 2025 06:26:55 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ClZhHStD; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.173 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740205615; 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=NIxIIVcpfvb6nwbQ771pqe0Neuy4l9HiGOBXAcMPLnM=; b=iWJAo6mDMq7JoTKhRDcZFU2JCEBQNuh3kNfFVYBl2iMI49BhzOf6OxqkVeVrpWCemGWVyS mCMivJCJyh+IG6InA0jkdlVA2mdOZaTnVSsWHOzEawB9i5a45fTMKz+gecFaUDbe0zW+Bt 8cVA29LVB/oOL/HIaIgvLsNKoebC2d0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740205615; a=rsa-sha256; cv=none; b=FJQYyrTLN4PDAJQ57Hwac6dpplgfmcxNdX7G0JIFbNn7CfR8xCuT7Ik4GDeU8X1zbjS0fk GyyQ2vEWX3cBgi5l7ZgS5LWtnU/Ky6/O6oIv6fPlGOrgeyXSo2617biQqhehbYJVqWrOq4 4e8amy+La5wdyEUCp37oI9I6z7Xuh0M= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ClZhHStD; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.173 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vk1-f173.google.com with SMTP id 71dfb90a1353d-5209437e773so851922e0c.3 for ; Fri, 21 Feb 2025 22:26:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740205615; x=1740810415; 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=NIxIIVcpfvb6nwbQ771pqe0Neuy4l9HiGOBXAcMPLnM=; b=ClZhHStDrleztWQOGgOF+3DzD/XcBX0blQ2r+NfnDUmE3CWcKZtL7Z9vx3x4yOiAR/ OqwFjkifYoaNyudMO86MbQkLl5Yemz4UfAQXi84cUG7BDzk9agfXVq8nmEzjpETolx98 132Z+UalruY3yvxyUoc8Ld4YgwqX9wW2pKweyltWGbtWxZi8Y2vh1jtW6px4br7vXn2V OrHA6rFGb2JoddXWOgvJRAjxg/hXqN6fYJKiuSODIiYrD3TwpAsbnU2+Vw3JKAPONMYo kqfs8l7jipZAGkV10fLWlJJQWhJcTFUesglMjAkxjKC23M6oYSu8zQe7bJUPHsq9KeO+ Bahw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740205615; x=1740810415; 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=NIxIIVcpfvb6nwbQ771pqe0Neuy4l9HiGOBXAcMPLnM=; b=pfZktb//CcJ/x7Sl7Qpb71lMUhVptypNJHRERmxA3ItU2PVUX7XwplrBAjB67E7tU6 1cW4jfwODFqMcUqkeiRE05/k4VVei+NrDRyx7My79iO3wMA8x8Mg/iX9J6jfpJCCqmSH 97zvxyd6ri7LSoUzgznoXpIPTMs/S8GdGr7CdG0kJMFjPTAC8shSijzRipyu0l+qIZ1k r4DJcsW+MbQ65FT/u1FgWxT82VYG6kUqJ5nVUF1vQcej8X4oSrgG6cOPoKXN9LXEqkQw QcIeRVjL7vUaJ4m68di33bAqagd9TFQXMyG65TLa/rKdKEgND50OpBg4yebNBLJXNGP4 0pYQ== X-Forwarded-Encrypted: i=1; AJvYcCV0SOU4FZSzehhMV3NNz+kFYGO4+5NT1CMQyQu9zzWCewRgkF7S0g7uLN7jVRQcrhsa/eNuIlLZqg==@kvack.org X-Gm-Message-State: AOJu0YxXQ4vrQwPd+r07kWEvu0dJ3uB3CHE2tOVVYXJ6Hwzz+ZYe1nHq lBQgtZiiYT3FN6QfPGJXb7YKskO6U2GPHJRnuScXyr2whfK+HUU5Y5e5/sq4XBfInGDE01DhuW2 qmU2l8PFYkKfoG3qgVvnBgxV6mVE= X-Gm-Gg: ASbGncuy6Y/mLk9MgT3wM/WN+PKrht8pUmFZjpCaKkevSmb7aE3hxlPzsokjg9FwIdx tR2F/Nfpb0g6Tk8hrNKUugIUeYPDtDuFaWB3B3E1jd3tgCTKalQC/yfhfyDWXlqRDPBmXaUTbxd JsLiA3k2I= X-Google-Smtp-Source: AGHT+IFiNhtcooCa0ZW3nQsQHTxZpb7DfLS1OFCj95hUoPmsr8UVPIUuHPI06xjCqFe90Conqt/5KRQtLGcyd/ySGv0= X-Received: by 2002:a05:6102:4b18:b0:4bb:e511:159a with SMTP id ada2fe7eead31-4bfc0165559mr4483805137.19.1740205614755; Fri, 21 Feb 2025 22:26:54 -0800 (PST) MIME-Version: 1.0 References: <20241221063119.29140-1-kanchana.p.sridhar@intel.com> <20241221063119.29140-3-kanchana.p.sridhar@intel.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Sat, 22 Feb 2025 19:26:43 +1300 X-Gm-Features: AWEUYZm78GL56nmXnRGMHD647u-GEBbD8ZLbSFkwxwXcyG1aAaf7Q47e3px4V3Y Message-ID: Subject: Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for compress/decompress batching. To: Yosry Ahmed , Minchan Kim , Sergey Senozhatsky Cc: Herbert Xu , "Sridhar, Kanchana P" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hannes@cmpxchg.org" , "nphamcs@gmail.com" , "chengming.zhou@linux.dev" , "usamaarif642@gmail.com" , "ryan.roberts@arm.com" , "akpm@linux-foundation.org" , "linux-crypto@vger.kernel.org" , "davem@davemloft.net" , "clabbe@baylibre.com" , "ardb@kernel.org" , "ebiggers@google.com" , "surenb@google.com" , "Accardi, Kristen C" , "Feghali, Wajdi K" , "Gopal, Vinodh" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: B16F61C0013 X-Rspamd-Server: rspam07 X-Stat-Signature: w1ytbeap9zw43umztatnqj9prq84ias5 X-HE-Tag: 1740205615-809954 X-HE-Meta: U2FsdGVkX18MAHj0jmSBQespJN9IKNIYPaBLS/2hpl1AlfuwnQkx+UvhXKtOC4ocrGlVAcglOENmlI4oILINnGKrlQmvmzuYirUJ5HKJme3eO2p0md10+WzZD1BFqKQZN9UIJj5R8BPysUjbl/Ntv5w7ksdR3/gv5N6f0uC5M0e77TNJKQLcfbT8vinwbu6y7DKEivBLVOBepcBAczBcEAD7Dc5LKnGRPg7dSKH6oOrsRsaW9/x9So3qjG5LbO1x/T2exyGE/mjE6QB8PjM9eO9j8DvZqrJxGM78Xt8+YxKnxgojfT9tcT+biiv/cMxiqT8YvVrbwqzY9ABGgvLs1WEEm3fdPjAKvhp+9kakcMLNDhenp915Pkn/knLneWlGa9UF+ml6P6C879C+ZB4xGbqb9wNoCDF9PK9XMLpBjSIsTzVrDBwYjo+F8li0hec+bVW8ERdTjzRg8k3UDCbYnnx70d03uy8cwOF1PPNdEc5sN/RmOdmM+hP0+yx1vR5u0Xdw7WTjNk5WRfB+ygeVTYhlZAQQ1BqVkopTDOHtubgK+dUdsWhanyavXTYLo5qRiTeAEBr7t/3JZLzpWZuGW5bIpXrPeu3aL3jMnSdDVJgpTL8oScnXe0BkujXhzK1lxOiqqEw/AyK/Kkes1VEQqtNDfCB7Ft7McXAyDmJXac5UjjHi2YSH5/MEMEHJDUnuYuSuMwyGQkwJR/XcyUh/5Hf9JrrTZoRXRwy1oIgbkaFPueNON/mMEmbgTE+bztOKOi6je+pvix5E6XlD7m98mTXGVDxDO+Y2o74wQtKASNYkKI9NT0JX+N05GabM5ZX3hq+G598ZTiSBUllbF0aUFXVyiN1UrSaDUnHEYau7/NLPuKM/dHi33Au+P/8WkqfzxGQDgtuTN6SIVnh14SOeuNQL9ehYwa1fj/cZHmxMFfqdYikH7gGhVqfZA1Yf/PqhAAxus5F9fZVGJ3Y4n5t dddOmCw5 YlzQIVlamXntM6yMpSywg1DCpI4ag17vY9H/Gq3VaexscWdG62gkXIBNqfozg1zvMWLIycUVY/70MKOjnenj0D4K8s0SV5wM+BhRkQMvW03MKi0pXIT6KkY4WqVm26QhYi8fr/tagouTKWPR3kaI4S9K5Q/s+YNb+xKBsyFnmNvueLIpp2lxUYb7QUXjmYfN4oUSfhrx6IJxSQlCFSCgUAdaHO31lcROAQLqnuyVGsThUc7lQUVRzBuePzz/Qw8KHA3GhJIHSEH9PY77sKf4hxH/EgMzg3s8KFH4Fuio6zinPjNgjv4Y/NE/zSYV20QftX5GbipPzU37r15sTBt+br9TQEiIw2hENEuz55D7f1rZEcVJ9T1MfF9nMC7nnYDX9b3u+YADhFGG3Gje4DiYKWfSHwHoY6ApySGduynPVOaie1frqDhUp000q5C2u8VlnOYgWmNlx6/CcHrx2uYBZqqdYZg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000017, 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 Fri, Feb 21, 2025 at 6:32=E2=80=AFAM Yosry Ahmed = wrote: > > On Sun, Feb 16, 2025 at 01:17:59PM +0800, Herbert Xu wrote: > > On Mon, Jan 06, 2025 at 07:10:53PM -0800, Yosry Ahmed wrote: > > > > > > The main problem is memory usage. Zswap needs a PAGE_SIZE*2-sized > > > buffer for each request on each CPU. We preallocate these buffers to > > > avoid trying to allocate this much memory in the reclaim path (i.e. > > > potentially allocating two pages to reclaim one). > > > > Actually this PAGE_SIZE * 2 thing baffles me. Why would you > > allocate more memory than the input? The comment says that it's > > because certain hardware accelerators will disregard the output > > buffer length, but surely that's just a bug in the driver? > > > > Which driver does this? We should fix it or remove it if it's > > writing output with no regard to the maximum length. > > > > You should only ever need PAGE_SIZE for the output buffer, if > > the output exceeds that then just fail the compression. > > I agree this should be fixed if it can be. This was discussed before > here: > https://lore.kernel.org/lkml/CAGsJ_4wuTZcGurby9h4PU2DwFaiEKB4bxuycaeyz3bP= w3jSX3A@mail.gmail.com/ > > Barry is the one who brought up why we need PAGE_SIZE*2. Barry, could > you please chime in here? I'm not sure if any real hardware driver fails to return -ERRNO, but there = could be another reason why zRAM doesn't want -ERRNO from the previous code comment: "When we receive -ERRNO from the compression backend, there's nothing more we can do": 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); } After reviewing the zRAM code, I don't see why zram_write_page() needs to rely on comp_len to call write_incompressible_page(). zram_write_page() { ret =3D zcomp_compress(zram->comps[ZRAM_PRIMARY_COMP], zstrm, mem, &comp_len); kunmap_local(mem); if (unlikely(ret)) { zcomp_stream_put(zstrm); pr_err("Compression failed! err=3D%d\n", ret); return ret; } if (comp_len >=3D huge_class_size) { zcomp_stream_put(zstrm); return write_incompressible_page(zram, page, index); } } I mean, why can't we make it as the below: zram_write_page() { ret =3D zcomp_compress(zram->comps[ZRAM_PRIMARY_COMP], zstrm, mem, &comp_len); kunmap_local(mem); if (unlikely(ret && ret !=3D -ENOSP)) { zcomp_stream_put(zstrm); pr_err("Compression failed! err=3D%d\n", ret); return ret; } if (comp_len >=3D huge_class_size || ret) { zcomp_stream_put(zstrm); return write_incompressible_page(zram, page, index); } } As long as crypto drivers consistently return -ENOSP or a specific error code for dst_buf overflow, we should be able to eliminate the 2*PAGE_SIZE buffer. My point is: 1. All drivers must be capable of handling dst_buf overflow. 2. All drivers must return a consistent and dedicated error code for dst_buf overflow. +Minchan, Sergey, Do you think we can implement this change in zRAM by using PAGE_SIZE instea= d of 2 * PAGE_SIZE? > > > > > Cheers, > > -- > > Email: Herbert Xu > > Home Page: http://gondor.apana.org.au/~herbert/ > > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > > Thanks Barry