Re: [RFC PATCH 7/7] mm: zswap: Use acomp virtual address interface

[Sergey Senozhatsky <senozhatsky@chromium.org>]

On (25/03/05 09:07), Nhat Pham wrote:
> On Tue, Mar 4, 2025 at 11:41 PM Herbert Xu <herbert@gondor.apana.org.au> 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@mail.gmail.com/.
> >
> > 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@chromium.org