On (25/03/05 09:07), Nhat Pham wrote: > On Tue, Mar 4, 2025 at 11:41 PM Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Wed, Mar 05, 2025 at 06:18:25AM +0000, Yosry Ahmed wrote: > > > > > > I think there are other motivations for zcomp. Nhat was actually talking > > > about switch zswap to use zcomp for other reasons. Please see this > > > thread: > > > https://lore.kernel.org/lkml/CAKEwX=O8zQj3Vj=2G6aCjK7e2DDs+VBUhRd25AefTdcvFOT-=A@xxxxxxxxxxxxxx/. > > > > The only reason I saw was the support for algorithm parameters. > > Yes that will of course be added to crypto_acomp before I attempt > > to replace zcomp. > > For the record, that's also the only reason why I was thinking about > it. :) I have no passion for zcomp or anything - as long as we support > all the cases (hardware acceleration/offloading, algorithms > parameters, etc.), I'm happy :) > > Thanks for the hard work, Herbert, and I look forward to seeing all of > this work. zcomp arrived at the right time and served its purpose. Back in the days, when I started adding params to comp algos, zram was still using *legacy* crypto (scomp?) API and Herbert made it clear that parameters would be added only to a new acomp API, which was a blocker for zram (zram by design did not support anything async or even sleepable). So the decision was to drop scomp from zram (this should have happened sooner or later anyway), enable parameters support (so that we could start playing around with acceleration levels, user C/D dicts, etc.) and begin preparing zram for async API. The last part turned up to be a little more complicated than was anticipated (as usual), but now we are reaching the point [1] when zram and zsmalloc become async ready. With this we can start moving parameters support to acomp, switch zram to acomp and sunset zcomp. [1] https://lore.kernel.org/linux-mm/20250303022425.285971-1-senozhatsky@xxxxxxxxxxxx
