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 6C436C021A4 for ; Mon, 24 Feb 2025 21:49:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0F2E6B0088; Mon, 24 Feb 2025 16:49:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BF736B0089; Mon, 24 Feb 2025 16:49:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 886676B008C; Mon, 24 Feb 2025 16:49:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6C6CF6B0088 for ; Mon, 24 Feb 2025 16:49:37 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C16D2C0108 for ; Mon, 24 Feb 2025 21:49:36 +0000 (UTC) X-FDA: 83156180352.14.BB292B5 Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com [95.215.58.173]) by imf21.hostedemail.com (Postfix) with ESMTP id D0A5E1C0006 for ; Mon, 24 Feb 2025 21:49:34 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=HbHhh+1O; spf=pass (imf21.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.173 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740433775; 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=n2f5hf7hxUD5ewFdsNAsjOnJ49wB0U6nGcYqVKwEfKc=; b=b+hZLGKdZExEUWFyS3YCdapwERCFRedScKe9rX9nJy+uJ4lO3J9t1JhHTDisItX8ZuLXPk 3u3DuMRYWupQ7AHs0ulNkHmjN2P0Us4RsAEYOUkyu6lB90bsB3aWdTn5xnWiGOVf3JcwMm X32OIt/Mh1ODo1DO/Pk2SilTEOGfIig= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=HbHhh+1O; spf=pass (imf21.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.173 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740433775; a=rsa-sha256; cv=none; b=4S5hprd4Yncl1Uus9lJxD9DAg541ElQD/4AsrLMI5wMqY6QF37FRNMHirxXTa1hdBSGsUh 9k2jPxv/+IJrNjiC3bkHqFEKpDr9E0Lz2BqNzxulYJD/0DHVAxa/6IpEomwzPTtGB1qOlm L55bcDFaRix0/FJmydagfMqFiWVqLQc= Date: Mon, 24 Feb 2025 21:49:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1740433773; h=from:from: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; bh=n2f5hf7hxUD5ewFdsNAsjOnJ49wB0U6nGcYqVKwEfKc=; b=HbHhh+1OHi8c9eqwewWNl1lgd12nNgByFLByUUmHpEbYHF7P2BOgA6a2LLDlgHfzBYzdUO WIJj1z1gIT95LtlhA3pT+DaE6SIx8d/YnC2bzFWXUk2v4QkbsvoUwBXgMorOJeah4kE17W DZSJhXxDxvSsPYFLPXqnIftUUfNCFjU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: Barry Song <21cnbao@gmail.com> 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" Subject: Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for compress/decompress batching. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: D0A5E1C0006 X-Stat-Signature: aqrk5q8rosbogqmpb75x9insqihxtpix X-HE-Tag: 1740433774-496737 X-HE-Meta: U2FsdGVkX19wUfDs4QXzmIzb1/u4I5M14aH+JM6VSxac08wQWB/XXeHlpqb+IjRAxKJo/1lD88KuU1U982F8qD583zXVXPfE9QfsKUr7tcEh1IWVpjH0CDwPLAvUAJQ1E3Tif7JgyN1PdvTa609Dfw3xhf8GrG7Tx04aGADMUQ6VNnwAkIvYzISSh5AWGdcZbBPscYSVSUYdY4/xa4vz+lr/0+NRI77WRY3iiAOoh8ueTw7L/1haUWaZTy7Y03PFXAbHOmsq4cRVUWldKo9kwPnT/SVMrdLSJRDrPEL4fcRI0MLb4G+5SWKdshuR4badE/NwC5KSzuxiHmIvBrnZhA2CSHhA162nCcLZ2mRSIBmy5wIa2/tp6dC4BYk5EHn+JH0avHUK9fojerdauxknuIRVO+ihZKDOtlQInW3I84iLq0I4ZBv68UqupMg0dMQ9EU58pWjBd7sq4SfsBVGKvpHNwIlT3YBnnz32CAp2gDCW26nOTb1GjsT/hW4+zRjrdbvO9chML2ePagHSf6iBca9EeEZHLVaV33Nm+NF3E0vOr+knXhmuKtiYKGxUpjqGeg6mut3jDjf10SPnf0QD/AqaMbAJopikDBjUkRT3yojLpr2btO427xPtsvox0IReAatD50ivSUY3e/XZPnkwmDDmxQOaCbXttLxVYf94vkwTjhwM07sK96TuroFIdw4NgrMs0KDcZjJ5t+tdMOmzME1KBzuXU1dIf9t+LxhhC7K4KCEJP/eTgeOVMMZ7ecDAY6PWvS2mNWmztX8Se7K3LpnjCy0L4A1j0qe2l/h5svBWlA1CJZoh12+lhLkzCsvDVaUMNolvBoAMDZYwHKPl9GRPhsymsJsezpiYOWZ36wIpHAXCzx/5DrXp9CqmiDdttpsp07DyTzsV/meBltNYHA4mLxUkvHoSRYWm8md1Z9ABWBEq5gDUtFGpv/wqFcjffJJmdB7l8qmnutOFQAD Y9gU/ocA fWPGzfC0VemN8VyhRJWTSjPNAPIfIKL8VOs5T7XglRROGCjN032Z1aH55/lngtKxr7BPSFKD/WAXfoZknwjdCB9dFig0V9cJgQCjhY0FWM8yeuLdmBOVUOdIPcS+hEC+uIk08i55/lWQg1NLEpkuzOnhi3mLR9F7Q2dZ1LezfU9JlHWd1cEJSlFX0Io5gd/vmxsKSXlMQai5Hi8vec74hRuaI533zzc1wq1b+PV6fEQZELYOBFYe8ZC1Gz7PhusEhPDxQy9mxw0k9uDTYtp+Nl4g3VfyplcAtR9UUwFnFpZ9zKaB9ij7VpzIq0uDIum0lnjAKxcrr74ndqwwCIiWYgHWtjQ== 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 Sat, Feb 22, 2025 at 08:13:13PM +1300, Barry Song wrote: > On Sat, Feb 22, 2025 at 7:52 PM 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’d like to see comments > 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 :)