On Sun, Feb 18, 2024 at 8:19 PM Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Feb 19, 2024 at 05:03:17PM +1300, Barry Song wrote: > > > > Not Andrew, i wrote a note in cover-letter and said zswap was > > the direct user for this patch, so it is good to go through > > mm. but it's also fine to go through crypto. > > Even if we decided to export whether an algorithm is sync or not, > the approach taken in the patch is not the right way to do it. > > You're exporting an internal data structure and making it available > to everyone. > > > But the problem of directly using scomp is that we are losing > > the chance to use hardware like intel/qat/qat_common/ and > > hisilicon/zip/zip_crypto.c to offload the overhead of > > compression/decompression as those drivers have no scomp. > > On the other hand, acomp with acomp backend can sometimes > > decrease cpu usage especially when PAGE_SIZE is big such > > as 64KiB while providing higher performance. > > No I'm talking about using scomp only in the specific case of > an unsleepable context. If you think acomp offload still > provides a sufficient benefit in that corner case, please > provide the data to back it up. Zsmalloc is the most commonly used allocator for zswap (and perhaps the only one). For zsmalloc, we cannot sleep while we map the compressed memory, so we copy it to a temporary buffer. What this patchset is trying to do is avoid the need for a buffer if we know the compression algorithm won't sleep anyway. This shows noticeable improvement in load/store latency. So it's not a specific case, we always have an unsleepable context. It's just that now we use a buffer all the time to handle the possibility of compression being sleepable. It would be nice to only use the buffer when necessary. OTOH, we can't just always not use the buffer as we would need to drop support for offload devices. Please help guide Barry into the best way to expose this information from the acomp API as you see fit, your help is greatly appreciated. Thanks!
