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