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 A68AAC021B8 for ; Thu, 27 Feb 2025 03:05:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 231B3280002; Wed, 26 Feb 2025 22:05:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E127280001; Wed, 26 Feb 2025 22:05:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 08195280002; Wed, 26 Feb 2025 22:05:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id DF1D4280001 for ; Wed, 26 Feb 2025 22:05:28 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9BFEC141664 for ; Thu, 27 Feb 2025 03:05:28 +0000 (UTC) X-FDA: 83164233936.24.FBD4335 Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) by imf02.hostedemail.com (Postfix) with ESMTP id B492180011 for ; Thu, 27 Feb 2025 03:05:26 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mCKqubWl; spf=pass (imf02.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740625526; a=rsa-sha256; cv=none; b=hVcCQRc8FYR/R3yd4OeMrAd1WMHz1CleOhELN2ROFh7JalYiCcjnQHka4KovtzV5N++tOA 3ssAr1heCFexYlx5792dilahMa9MBMLHiS/P9zkEOE7v3NhWnBUNxpsYjdeOACMGbAQ24q KNCj9GF+KGpZQ9dEjkAGgL/ZCCiDFP0= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mCKqubWl; spf=pass (imf02.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.41 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=1740625526; 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=IXVx49eJQBLxbCrIlxbeeYi4KBlOK0BbrpMyI4DO0vk=; b=P1B4W4DP/QUuAjA11l4SJ9Rp9Fls7YBHrbJASfvaFMDbdVXMXtwXeaJ9SdFS9s1oGWHT6N 9VjKRe5fxj0zt9CCUaDxOdzu4u3DgqbzkA5iF7a7lyNfDf0UMw4Fg5gbzuH4rBHIciQmAp DtwQgN7oCCNaLTW+kx4RyCvaJENSA/k= Received: by mail-ua1-f41.google.com with SMTP id a1e0cc1a2514c-867129fdb0aso393154241.1 for ; Wed, 26 Feb 2025 19:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740625525; x=1741230325; 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=IXVx49eJQBLxbCrIlxbeeYi4KBlOK0BbrpMyI4DO0vk=; b=mCKqubWlU3fnBvQU2K67H3QtYjBEMTCnTYVNv2BQ25xC0kCYwgyAP3F8rqvjgAYbvX I6nj8U+5yStqfJXL7mG7EHzsvuG+Tx+TGSoavBM5bmbfKLkcleibXRT7ySjbFwx/GRfD Nar12OTUIu8GTUZOEzBJeOGBx2sXq/agNh5PsgM2Z5nK4kTin9jQiyC5kUInSC299vKo e57XtgFWG5jF2IoURoOh5RM9tTBnSD/hOyogVj0/1XFKENwNpCET8mE2VcxG3XL6O5sH eAgE7WMfwsdSPDhFBu6LUKvAB7uzhZj2Xnka1OP49ZPlp6DTL4JoZJePKwS+s6nwCmWB ZdYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740625525; x=1741230325; 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=IXVx49eJQBLxbCrIlxbeeYi4KBlOK0BbrpMyI4DO0vk=; b=ToMeDJQyZhOvxOcDkjzW245PmGexDUhdPGNYxdXh30ddm5nYchPrlrOC5sMhQOT7sa pscr7Zp55BPlqsMsAVrSZ9Dy57nPYsZFf/uLpoyWyCs1xVrungfTT0bVSJ4gD5wuhqzA tBl9j4P4ukyWfxiPAaBkrOgJUluXY6Ux24PNfOfLnz4VgDoAip3NLeNXoZWiNnXUm5v8 k7sL5+mjuBj34VAoW8nGPCE+F/opR/cv9ey4iCAu46jgudvaZrAxFahJ9GV2b/GIbfu+ +JVMmp1Z0qwg9fl4W0j3g6fDYGUswIex5FKRlHnXls8EahE71kww7FzJ7oRbvlExWyyS XPvg== X-Forwarded-Encrypted: i=1; AJvYcCVyZFi6Ruo9prkgdbPdqi7f61Xtd+FBbAYUIPHtxV5lSUptG5eak7sgvldCi7lF5qiZLmNRbb8WGQ==@kvack.org X-Gm-Message-State: AOJu0YwBrMyALAsobclCJfJaOUN1I9DSFKjq5rmXoR/+UPCqP4CLv760 lDkdcjW6AScNwRxc8kCsTggFSx/muCEdHf84VfG3xDsCuOpM2ugdPF9T6/HbWPwqkReFYRpGkfK qwHf7qM3KM0rEnOSFMovpTDSYcTQ= X-Gm-Gg: ASbGncvVb0RMDm2slHvn6a/L8gn/psqMD4a1ZAWpZ/WY2sEf4jR07j2Lq7exa2+Cqz/ enHV5WtfLmVQSJwftkpxQQudcbk78ArSrWwzG/x5pecCXORnsY6Z7gAnYT3kvB/DsULm9Yw9JW7 lHphBSJck= X-Google-Smtp-Source: AGHT+IFyyL3QwKMRRIxrajlGaeKqkP2l4r4cTYgFE9XLJOhNICubo3hunk6zTvETFEecuXEDORjBfHeBIuyCQFpuRBM= X-Received: by 2002:a05:6102:1614:b0:4bb:9b46:3f6f with SMTP id ada2fe7eead31-4bfc27aed9fmr12833741137.1.1740625525584; Wed, 26 Feb 2025 19:05:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Thu, 27 Feb 2025 16:05:14 +1300 X-Gm-Features: AQ5f1JqXTKth9otrpj1zvCFqiq4wqPtE2SBEWuDVtOaMhsKlJKNsoIq3Jx_5obQ Message-ID: Subject: Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for compress/decompress batching. To: Yosry Ahmed Cc: Herbert Xu , Minchan Kim , Sergey Senozhatsky , "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-Stat-Signature: f6homq5fk43w4bz6hoq4bag4a537diyu X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B492180011 X-Rspam-User: X-HE-Tag: 1740625526-132127 X-HE-Meta: U2FsdGVkX1+DxNlDgCj9CHp4Bqj1MY+3hQLKyBRXhVBTv5yRpVJwpqs4Goj2PXkdP403Q8EPpA9334eFRnQd9ARzdUgh/CkJP+cDlSF9h8JP/2xBTqKHuSOueAjbgZTB91oapqhjf1Y4UBD6XaUxcg/39spNaitngM8AvCgHqujDgZkz9LuIukTo8jBC0/gKrQ5EPhD7Nn/n/sJA/fte9BLwr/ym7CrAmh2/DrbzGNTQgpfreoPd6NTE+3sYC8kIgtmzDTIcpTkdvWh9hHXQyct/zn8hAU9IjE+DD8ps5B4UuOtlqqx8jOrzUvZG9eR7Kyjowu+f1Jg6FWQ80YM5tGpeBS+91pw8v3of6JdlqPWTnQABeWDeka9e6bEIUksvLk+05SmwBNQ7U83slbPJtBFjzq8KH0H5kfzo4Rcfr3UlaB3Bk2EivgpFNz5x50ZAwAfAK3tK5ZpY67Z+mGDxKGRA1NwypCJbUrhKbQw20zIYdG3Y7zr1N2u53aNoOTKXXiMwuM2PAfz5cMvTStyShXw7hHQUX4cKgb2Y9Uhz3SlmwkVGRaIOUU2ioh98F9cS+kRstruPWKwyFBdZbeo9xHLdARLV0aJ9JFtoKRA8ClP+GDYfCo7ppmEijCTF6j+vJG9s4uXucrEeRzIqjnPATyVXZWss3rCA13TRHc35tjYYwJz2JoBxRutvR1VqEr8/xVRgoNUeZyu+Ype7pPXuoOdT7F6AofAwEdlVfC80yZGClyaZga40aphsJh6jBDHVlV+fdXIY26i2bWtWEQzkVbSnAvXje9k+IXYnq5ymzMUn+cfcrPIiymyghEp+Gz3IVsX8DIWzERZBqPSd5He8X3jGW0E8qM69ZvWQskuQl8hWpZZTB29sUohyy+3roCKrPtztpa7hH7hDa5z/DNcuUYUCOswwca16xkxnnzBT/Tx+neIPAXEscInxEebVtdIwMKxObXl/7OnZKeynpXk F5ThBqdf yw0nLpFuc72gX42xYRf+uqIsGJmE/H8h7APcaAgg4GzuQYnJWJCt2ixTO/9jTfhHky4/TUS6TNqsxMVIkmUPzrT7sRQgSCNnsTMXsXgEoIp5AvjHX7vn4dRvLPzrXKr/64wxBZQFSWTHHxsXluIon4SW9RxVBxtTEkSnfUIaRdPyaY1tBoWUjLL9BY3UQRzaaaVonwS8L1zLb0rXdjnqmL+vFW/F7vB/bSwJD1o00zsL50Hp6TFUdFa4exIrMMpbw3SzmC+/cD9Nw+LfDfMAHwv79bg8M/OmQ1wN2seu0/3ojVYhDenVp5ET1+sw5NrbxbejOqMmw540SRhdmKG7PpM5KOpAS2eNtjdm+TJDOeeJTr+LwoEjU3/FS1dTBFvpVOQOJ8wRffj4bSbQYj4ekGJjd2ST4jBITxbKtHFxralgGjSZFHSbiWHMfqdPSjZvn+Tcc X-Bogosity: Ham, tests=bogofilter, spamicity=0.000009, 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 Tue, Feb 25, 2025 at 10:49=E2=80=AFAM Yosry Ahmed wrote: > > On Sat, Feb 22, 2025 at 08:13:13PM +1300, Barry Song wrote: > > On Sat, Feb 22, 2025 at 7:52=E2=80=AFPM Herbert Xu wrote: > > > > > > On Sat, Feb 22, 2025 at 07:41:54PM +1300, Barry Song wrote: > > > > > > > > probably no, as an incompressible page might become compressible > > > > after changing an algorithm. This is possible, users may swith an > > > > algorithm to compress an incompressible page in the background. > > > > > > I don't understand the difference. If something is wrong with > > > the system causing the compression algorithm to fail, shouldn't > > > zswap just hobble along as if the page was incompressible? > > > > > > In fact it would be quite reasonble to try to recompress it if > > > the admin did change the algorithm later because the error may > > > have been specific to the previous algorithm implementation. > > > > > > > Somehow, I find your comment reasonable. Another point I want > > to mention is the semantic difference. For example, in a system > > with only one algorithm, a dst_buf overflow still means a successful > > swap-out. However, other errors actually indicate an I/O failure. > > In such cases, vmscan.c will log the relevant error in pageout() to > > notify the user. > > > > Anyway, I'm not an authority on this, so I=E2=80=99d like to see commen= ts > > from Minchan, Sergey, and Yosry. > > From a zswap perspective, things are a bit simpler. Currently zswap > handles compression errors and pages compressing to above PAGE_SIZE in > the same way (because zs_pool_malloc() will fail for sizes larger than > PAGE_SIZE). In both cases, zswap_store() will err out, and the page will > either go to the underlying swap disk or reclaim of that page will fail > if writeback is disabled for this cgroup. > > Zswap currently does not do anything special about incompressible pages, > it just passes them along to disk. So if the Crypto API can guarantee > that compression nevers writes past PAGE_SIZE, the main benefit for > zswap would be reducing the buffer size from PAGE_SIZE*2 to PAGE_SIZE. > > If/when zswap develops handling of incompressible memory (to avoid LRU > inversion), I imagine we would handle compression errors and > incompressible pages similarly. In both cases we'd store the page as-is > and move th LRU along to write more pages to disk. There is no point to > fail the reclaim operation in this case, because unlike zram we do have > a choice :) Yes. For zswap, I suppose we just need to wait until all driver issues are resolved, such as: crypto: lzo - Fix compression buffer overrun https://lore.kernel.org/lkml/Z7_JOAgi-Ej3CCic@gondor.apana.org.au/ for zswap, we just need to address point 1, which is not the case yet. " > 1. All drivers must be capable of handling dst_buf overflow. -Not the case. " Thanks Barry