On Mon, Feb 19, 2024 at 5: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. > i agree this might not be the best way, i was looking for a better way and i couldn't find it. actually sent an email to you regarding this and asked for your help before[1] :-) [1] https://lore.kernel.org/linux-mm/CAGsJ_4yk=yrpBWvYukoDbq8288yqLLyox4ozg82GiUyaU+ntWQ@xxxxxxxxxxxxxx/ > 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. The difficulty is that we request comp at the beginning, with acomp api, its backend can be either scomp(if hardware has no offload) or acomp(if hardware has no offload and algorithm is supported by this offload). we can't dynamically switch to a scomp api only within an atomic context. and once we are using zsmalloc, we are always in atomic context with no exception. so it isn't a corner case for zsmalloc. The patchset is aiming to fix the performance for hardware not using acomp offload - which is true for almost 99% hardware in this world. offload should always be a good option, the only question is here if we allow offload driver to support scomp. i think the answer should be yes. i think it only makes sense to compare: offload by scomp vs. offload by acomp it doesn't make sense to compare offload by acomp vs. CPU compression/decompression by scomp. this is comparing apple with pear. I think it makes more sense to discuss dropping acomp support in some cases of zswap after crypto opens the option to allow offload driver support scomp. offload is much faster, but while page size is smaller, async wait/wakeup might cause latency. so busy-wait in offload drivers could be better for small sizes like 4KiB. I do agree a lot of data is needed to back up the above discussion. but I will need Zhou's help as I don't have hardware with an offload driver now. Would you consider this as an incremental job after this patchset? > > Thanks, > -- > Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt Thanks Barry
