Re: [RFC PATCH 7/7] mm: zswap: Use acomp virtual address interface

[Herbert Xu <herbert@gondor.apana.org.au>]

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).

Once that is done I will repost this.

Thanks,
-- 
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