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

[Yosry Ahmed <yosry.ahmed@linux.dev>]

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 <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt