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 C9AEFC021B8 for ; Tue, 4 Mar 2025 20:47:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B4F06B0088; Tue, 4 Mar 2025 15:47:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 465E06B0089; Tue, 4 Mar 2025 15:47:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3544E6B008A; Tue, 4 Mar 2025 15:47:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 19F5C6B0088 for ; Tue, 4 Mar 2025 15:47:57 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B3A78A40C6 for ; Tue, 4 Mar 2025 20:47:56 +0000 (UTC) X-FDA: 83185055352.24.20B015A Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) by imf09.hostedemail.com (Postfix) with ESMTP id D14AD140002 for ; Tue, 4 Mar 2025 20:47:54 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=JKqWnzP+; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf09.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741121275; 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=X99rcIZ7WjEg9GvuSuB4QRdl5cFkDXpH18r5TwlZpiI=; b=g0TSy2A/ALZoxaHU+hXptrdhAV6rXq7ktBnyRqXztA+S05CPRBjGDY7D9KMV1cGDiM2E3o j1BO2BpE0ggx/ixAnTbcmGWVPS+iyhfhnFM3Xktuj7ddsvEnP+I5eYISWil3PgJfB+Pz/z Zb7Oc86TLFolQmO/V2TOgnKTDQISXV0= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=JKqWnzP+; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf09.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741121275; a=rsa-sha256; cv=none; b=ZPq/xohvtkPZM2kJBNLaA2220a/RGZt74gRSweleyEH+OBrvQhrPVa1OjhDVv8I6pg0iUi ZhrPaw2AgYMYuzQmkvGbvPD5U/zprI6r+548chmVd1qwIOinqdT7OTrBk7S/jxIUloxZar kL11iXvTEWWSGP2PCC60xESEMxokhDM= Date: Tue, 4 Mar 2025 20:47:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1741121272; 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=X99rcIZ7WjEg9GvuSuB4QRdl5cFkDXpH18r5TwlZpiI=; b=JKqWnzP+aoryMF1BdHdqg8rEOeYkf/q8iqJpFnKHXcvvxlIo4AsavhnHRdmJO+NK4SPbQ5 dBGzilvuBEpMFuBvoVG7f8dRhN1nLmqP4BxGRtinoUMoy5ueLZn126otQrN02t7hkF/b7g cY8iN7vFP+0G1Bgz1irKhMYBcsekGrk= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: Sergey Senozhatsky Cc: Herbert Xu , Eric Biggers , Linux Crypto Mailing List , linux-mm@kvack.org Subject: Re: [RFC PATCH 7/7] mm: zswap: Use acomp virtual address interface Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D14AD140002 X-Rspam-User: X-Stat-Signature: w31mqqu6n5ue9tb6y1gyc6mh17jtmqp9 X-HE-Tag: 1741121274-821167 X-HE-Meta: U2FsdGVkX19fqR8Vp71yckFrR5ZRqo64vLS1RDd7UfZjdoe0M060Bam/R0ItecKOUFTiqHOsK/o3UaMe0RmYZo++1UbwuZ+6/qsm+uygsQCtUmCx6H8NKrvm9tyefre6fKzN5AYzySNxOAQ10lNMgQeV0rFUuwI47EzwFuaIH3awNvrcLMnjPEuwxbd7nintL5B0rJ77Q5J87lOnUCmuY3PSxk84pmYLX73xwC54bpRkqly4kLs23osqg4NIEW/xIBOaK3wcAk3gMIju7bh7c9M2lf5HgqEwvt99VJMELDJqAfjDQyTiEJaBX1K3KDkCC1PVn0FoImoWFAk/yjCuKGZT5zgSDg7FkQ/GEzs/sY6AZPdZtz1ghCe2ACNPNK8WpxjIk1eFxL2HlyDyp+XVIzhCaJDMDrRlqF0ShuF0NscLpUv7zhOsyaSU/eoV2goPVA6/dAcGmW8O6R5KDy2LEGtHxgOF6ZOlbzS5uVIlPReeO8LVac1Y+g3VIwBqQSUd9UfY7E7fzUE93lbdA3sLzuELTDJu9/ntszFXQyqpgsvyXxzIrBY9AbwvooCIHQLKNJscTw/cZXVTH1e5DIJVtFGY3lCXjtYlp2qdlhd5WbNmGNgNABwfFl1afKEDrYQF3+XrpzUOkaIyGXJkmpPUcIgUDFlqkZdQnrS/yiWJCzFfxA56XekT9LjwRRodFVvL768S586/DUwJshLRlHJVSP9ZJwougc2sK4KKwaMyR8sAS1R/Spq5O2/eYlJSvWbDvcySxIySbZYko4ftSl7UCSxu7F3AlPJbiQmcQ88Ek90XTw+m9DAzeLmDgHpe5EWiEWCAGSw3OsWFKUGEgQVCKKzyYLxKemEz3Xo95eIa/BrfNekl9JJVWWyy7rmV17s5MYlse3d8CC8xeEptb/Lf44+H7LHJwaiMYbhm8bTAynAnScFc/jdz1tbOHTTPg+HJw7XJz5eDMunSouCzlgL fht7nd1w 7192G8YfvEEWfHnLnUSBv9AbeEmu7gcgSKI7D8Zth5Efb+o0QMViJHyMETyTkmYPHe4f2FBANYUI7rV+Wq3fZ3DFwp+0qOmjV5rAMxx7BD3L3veLdb1HdV4JITsnOQQQohQfKiQn4hnxv2xNmSyG3qTUqg2c0LVPmC4u1hxlbTDAO7WPc6TsQ7ORL3boOnNzqZeKYV5pSSIf+LsxeppOSyHpm3Q== 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 10:19:51PM +0900, Sergey Senozhatsky wrote: > On (25/03/04 14:10), Herbert Xu wrote: > > +static void zs_map_object_sg(struct zs_pool *pool, unsigned long handle, > > + enum zs_mapmode mm, struct scatterlist sg[2]) > > +{ > [..] > > + sg_init_table(sg, 2); > > + sg_set_page(sg, zpdesc_page(zpdescs[0]), > > + PAGE_SIZE - off - handle_size, off + handle_size); > > + sg_set_page(&sg[1], zpdesc_page(zpdescs[1]), > > + class->size - (PAGE_SIZE - off - handle_size), 0); > > +} > > + > > +static void zs_unmap_object_sg(struct zs_pool *pool, unsigned long handle) > > +{ > > + struct zspage *zspage; > > + struct zpdesc *zpdesc; > > + unsigned int obj_idx; > > + unsigned long obj; > > + > > + obj = handle_to_obj(handle); > > + obj_to_location(obj, &zpdesc, &obj_idx); > > + zspage = get_zspage(zpdesc); > > + migrate_read_unlock(zspage); > > +} > > One thing to notice is that these functions don't actually map/unmap. > > And the handling is spread out over different parts of the stack, > sg list is set in zsmalloc, but the actual zsmalloc map local page is > done in crypto, and then zswap does memcpy() to write to object and so > on. The "new" zsmalloc map API, which we plan on landing soon, handles > most of the things within zsmalloc. Would it be possible to do something > similar with the sg API? Yeah I have the same feeling that the handling is all over the place. Also, we don't want to introduce new map APIs, so anything we do for zswap should ideally work for zram. We need to agree on the APIs between zsmalloc <-> zswap/zcomp <-> crypto. In the compression path, zswap currently passes in the page to the crypto API to get it compressed, and then allocates an object in zsmalloc and memcpy() the compressed page to it. Then, zsmalloc may internally memcpy() again. These two copies should become one once zswap starts using zs_obj_write(), and I think this is the bare minimum because we cannot allocate the object before we are done with the compression, so we need at least one copy. In the decompression path, zswap gets the compressed object from zsmalloc, which will memcpy() to a buffer if it spans two pages. Zswap will memcpy() again if needed (highmem / not sleepable). Then we pass it to the crypto API. I am not sure if we do extra copies internally, but probably not. The not sleepable case will disappear with the new zsmalloc API as well, so the only copy in the zswap code will be if we use highmem. This goes away if the crypto API can deal with highmem addresses, or if we use kmap_to_page() in the zswap code. IIUC, what Herbert is suggesting is that we rework all of this to use SG lists to reduce copies, but I am not sure which copies can go away? We have one copy in the compression path that probably cannot go away. After the zsmalloc changes (and ignoring highmem), we have one copy in the decompression path for when objects span two pages. I think this will still happen with SG lists, except internally in the crypto API. So I am not sure what is the advantage of using SG lists here? The only improvement that we can make is to eliminate the copy in the highmem case, but I think we don't really need SG lists for this. Am I missing something?