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 B249CC021B8 for ; Tue, 4 Mar 2025 04:30:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D0DF6B0082; Mon, 3 Mar 2025 23:30:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 081136B0083; Mon, 3 Mar 2025 23:30:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8C026B0085; Mon, 3 Mar 2025 23:30:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id CC27F6B0082 for ; Mon, 3 Mar 2025 23:30:10 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6A93D53780 for ; Tue, 4 Mar 2025 04:30:10 +0000 (UTC) X-FDA: 83182591380.12.B806887 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) by imf22.hostedemail.com (Postfix) with ESMTP id A030AC0005 for ; Tue, 4 Mar 2025 04:30:08 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=gUsKSdWm; spf=pass (imf22.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.179 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=1741062608; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rNv/Glifk73jt7z0FPmxZX8Vcu3aK9Hgz6Mjj5M3NBc=; b=rGPxfx+tqZ/ZrSfPkpnvVUU56oLoZ1s4Hy1ub8CuwX8iHjBXbY8/f4Oce22fS5zXKdAGps 19OUal+UayEzBEx86pDaXUtmtlQOtG0814Cjm8hsQQjh+9vzmkcY4vCKXUhMea1ddBjTG+ rUbjkyEmOhsPkfHctlSIFo/pJ/nQxYc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741062608; a=rsa-sha256; cv=none; b=P8yE7MhdxwqujNmRyghEJOMxXcTdFB8mG/5BuJXlfn3Pia3HVT74uQSwkyURA/LSBxgAz6 10qZOBBByehjFxdNMKNbTehyCO5goza1GDT7RM9hpJMJCGjAPpsIDPmOllmbLBFrxCYIbL JbkLdGFSjEjWgN1wE9mYqhRC2gkWuY4= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=gUsKSdWm; spf=pass (imf22.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.179 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Tue, 4 Mar 2025 04:30:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1741062606; 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: in-reply-to:in-reply-to:references:references; bh=rNv/Glifk73jt7z0FPmxZX8Vcu3aK9Hgz6Mjj5M3NBc=; b=gUsKSdWm+gRoNk+ML0cx0WgrTmOCCig5oBv/YDjmxXneM6lDr7+zizLoe9qMrd3A9C1uUa encG6Q9K+p4cFyx2xmm2WqpMAkuT+xoRb5hRuNmHwVB9CUH0d2fAkVCtWYHgUPWzY6sLhn JGhqJepQBHYeo+sT0JM8SzsX+YIYmes= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: Herbert Xu Cc: Eric Biggers , Sergey Senozhatsky , Linux Crypto Mailing List , linux-mm@kvack.org Subject: Re: [RFC PATCH 7/7] mm: zswap: Use acomp virtual address interface Message-ID: References: <20250227183847.GB1613@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: kbjn6osyameqbrycja6wfhusnr1cq4ft X-Rspamd-Queue-Id: A030AC0005 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1741062608-890425 X-HE-Meta: U2FsdGVkX19IxQnGcLLhI+75HZlpAMCsmD4NbxlyRbqTEjUoIT9MTVFUYnHYmUbvu3YWvG5KI6r1vcQnTzANZSQgubvCmFvGiZ4kjLYOZNwLPiudkGQ3ke+m1K6Ok0CjshmrlM3SBJ8m78iA6xRAG8XXFS5WeOFN4oQf1pvqAl2f+DRwd857qgvZPqM8iwsBYAG+2iwrg9FuUEP67tWycp1M5CNk9k07zxKpiL3IbLXgCm3Y0WjT7ZGK5CzJtzJKZaS/QVH7fIoDIIP6O3QPJISD2BJJcymrH/zirDbyItQcSc0Llgoc8SOQr5oMxx/EGiwwyowRV42ll0KnYSPiVvW+jnfaSzPoep9WMNpskmVO6WwT2bXmmETOxQSSj/uFQMND0kBBi6AHW8QVM0yjCuZXEdYRAYqm8pVKXDpQtPW0xaJXUrO1asoRM9Vu1JHxsUwCTa3TUe1kAOpJ6oaPeFqNwQKuNyWbVTV/crtrxmRgrY4oGT1F5dG1Fm4gBJ55wUFlSxFlTLeOIm/S+UN1h1il3Or1wUN/Gd9OnYszo8yE6yN5m+ch3jalnnjaaYkPoxcV3O8NmVSB1uY7d2z8UG6J/Q2kxYBU1cbV7BGR3vBBk3dazV4sqNYfg9NFKzaOvL7WbB4vFHueAyeRxZaKpe2bq5k2fU5/nUqD32KUshUafS1GrSBNeCxgepg4Zb2XclZJmc/P79/sKnHOcfvG1kkwHcFn8L+4dKYaAr7WEGo0b1frrEUszH3ftzxmeTWfr+lM5C7VCBpywiYix9rLLoUH1l7fRaHWUPiCUvqTttxjiOQBBLGBh317t14GDrSJ+inAfb++hC7f8gRVPi3XrbglImLdDtIydJivHYthfo03cW9JouRwLdhNN3quLgZ6wjbc7dEhJJSEQK9vcevYFa+2tEhq0akAGEtdNWfBnf0cvV0feH2MyLedgz5SbXGRRj/kicyvt7uJV1ZHi3U Yi/sdztR yacjJozWf6xT3D+NGkIX0oRJ1x4DWMIR8ONMDaTOt+S12sBESUgLPl/6wZYgEKa7vffdfkbuRa06DS8Yeu5YPQ5A+TTytRKAuO288tPujjpPWuDAdtHxlYS2vty8nFcMcxe0IQYka3yHNNHBGCOT/8Pvohv8SbhiDFX7KoTbCfD1KmcSlWNNOAAN4wyRVNlusl//MswAz4n2BjkLMBh6z2dD1ZltOuKWiQBzEbEBsLMqratwx/hDfzbNEQxwk3gyf7PJouwxqN4yyLKk= 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 Tue, Mar 04, 2025 at 11:29:44AM +0800, Herbert Xu wrote: > On Mon, Mar 03, 2025 at 08:17:27PM +0000, Yosry Ahmed wrote: > > > > I have seen the other thread with Sergey, I believe the conclusion is > > that zsmalloc will be updated to use SG lists, at which point zswap can > > just pass this as-is to the crypto API, and we don't need any copies in > > either zsmalloc or zswap. > > > > Is this correct? > > That is my hope yes. > > So there are two reasons why zswap should be using SG lists: > > 1) Non-linear memory because compressed object spans two pages; > 2) Highmem. > > > Will this patch series be dropped? > > Not comletely, I rather liked the simplification of the scomp scratch > code. And the chaining functionality is still needed for the batching > work. The virtual address support will disappear for now but could > always come back if someone wants to do that. > > However, I will reinstate the scomp scratch buffer in a more limited > form just to cater for the need to linearise things if the algorithm > does not support non-linear input (I hope to modify the algorithms > we care about to support non-linear input but that's going to be a > long-term project apart from LZO which I've already completed). > > Right now there is a proliferation of per-cpu buffers throughout the > zswap/acomp call-stack. I'm going to consolidate them so that there > is a single per-cpu buffer for everything (the stream memory, and > the linearisation buffer), and that it only comes into play when > needed (so hopefully LZO decompression will become completely > preemptible and not use any per-cpu buffers at all). Looking forward to this :) > > Once that is done I will repost this. > > Thanks, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt