From: Yosry Ahmed <yosry.ahmed@linux.dev>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Eric Biggers <ebiggers@kernel.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: [RFC PATCH 7/7] mm: zswap: Use acomp virtual address interface
Date: Mon, 3 Mar 2025 20:17:27 +0000 [thread overview]
Message-ID: <Z8YOVyGugHwAsvmO@google.com> (raw)
In-Reply-To: <Z8KxVC1RBeh8DTKI@gondor.apana.org.au>
On Sat, Mar 01, 2025 at 03:03:48PM +0800, Herbert Xu wrote:
> On Sat, Mar 01, 2025 at 02:36:50PM +0800, Herbert Xu wrote:
> >
> > I thought this was a lot more complicated and you had some weird
> > arbtirary pointer from an unknown source. But if it's just highmem
> > I can get rid of the memcpy for you right now.
>
> So it appears that your highmem usage is coming from zsmalloc. In
> that case you don't want virtual addresses at all, you want an SG
> list.
>
> In fact you've already gone through a totally unnecessary copy
> in _zs_map_object. Had it simply given us a 2-entry SG list,
> the Crypto API can process the data directly with no copies at
> all.
>
> The whole point of SG lists is to deal with memory fragmentation.
> When your object is too big to fit in a single page, you need an
> SG list to describe it. Forcing virtual addresses just leads to
> an unnecessary copy.
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?
Will this patch series be dropped?
>
> Chers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
next prev parent reply other threads:[~2025-03-03 20:17 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-27 10:14 [PATCH 0/7] crypto: acomp - Add request chaining and virtual address support Herbert Xu
2025-02-27 10:14 ` [PATCH 1/7] crypto: iaa - Test the correct request flag Herbert Xu
2025-02-27 10:14 ` [PATCH 2/7] crypto: acomp - Remove acomp request flags Herbert Xu
2025-02-27 10:15 ` [PATCH 3/7] crypto: acomp - Add request chaining and virtual addresses Herbert Xu
2025-02-27 18:33 ` Eric Biggers
2025-02-27 10:15 ` [PATCH 4/7] crypto: testmgr - Remove NULL dst acomp tests Herbert Xu
2025-02-27 10:15 ` [PATCH 5/7] crypto: scomp - Remove support for non-trivial SG lists Herbert Xu
2025-02-27 10:15 ` [PATCH 6/7] crypto: scomp - Add chaining and virtual address support Herbert Xu
2025-02-27 10:15 ` [RFC PATCH 7/7] mm: zswap: Use acomp virtual address interface Herbert Xu
2025-02-27 18:11 ` Yosry Ahmed
2025-02-27 18:38 ` Eric Biggers
2025-02-27 21:43 ` Yosry Ahmed
2025-02-28 8:13 ` Herbert Xu
2025-02-28 9:54 ` Herbert Xu
2025-02-28 15:56 ` Yosry Ahmed
2025-03-01 6:36 ` Herbert Xu
2025-03-01 7:03 ` Herbert Xu
2025-03-03 20:17 ` Yosry Ahmed [this message]
2025-03-04 3:29 ` Herbert Xu
2025-03-04 4:30 ` Yosry Ahmed
2025-03-04 6:10 ` Herbert Xu
2025-03-04 8:33 ` Sergey Senozhatsky
2025-03-04 8:42 ` Herbert Xu
2025-03-04 8:45 ` Sergey Senozhatsky
2025-03-04 13:19 ` Sergey Senozhatsky
2025-03-04 20:47 ` Yosry Ahmed
2025-03-05 3:45 ` Herbert Xu
2025-03-05 5:58 ` Sergey Senozhatsky
2025-03-05 6:05 ` Herbert Xu
2025-03-05 6:18 ` Yosry Ahmed
2025-03-05 7:41 ` Herbert Xu
2025-03-05 17:07 ` Nhat Pham
2025-03-06 2:48 ` Sergey Senozhatsky
2025-03-05 3:40 ` Herbert Xu
2025-03-05 6:17 ` Yosry Ahmed
2025-03-05 7:46 ` Herbert Xu
2025-03-05 14:10 ` Herbert Xu
2025-03-05 16:25 ` Yosry Ahmed
2025-03-06 0:40 ` Herbert Xu
2025-03-06 16:58 ` Yosry Ahmed
2025-03-01 7:34 ` Herbert Xu
2025-03-01 7:38 ` Herbert Xu
2025-02-27 18:11 ` [PATCH 0/7] crypto: acomp - Add request chaining and virtual address support Yosry Ahmed
2025-02-28 9:02 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z8YOVyGugHwAsvmO@google.com \
--to=yosry.ahmed@linux.dev \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=senozhatsky@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.