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