Re: [PATCH 00/15] add zpdesc memory descriptor for zswap.zpool

[Yosry Ahmed]

On Tue, Jun 25, 2024 at 10:22 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Tue, Jun 25, 2024 at 3:32 AM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote:
> >
> > On Tue, Jun 25, 2024 at 1:11 AM Alex Shi <seakeel@xxxxxxxxx> wrote:
> > >
> > > Thanks a lot for the info and comments! It's my stupid w/o checking the email list before work on it.
> > > Anyway don't know if z3fold would be removed, jut left this tested patchset here if someone need it.
> >
> > It's partially our fault for leaving z3fold knowing that it is headed
> > toward deprecation/removal. FWIW, I tried to remove it or mark it as
> > deprecated, but there was some resistance :/
> >
> Our apologies, Alex. Thank you for your contribution regardless!
>
> Regarding zbud and z3fold, this is the second time this conversation
> has come up within a week or so. Chengming was trying to revert the
> multiple zpool changes. zsmalloc (after we re-introduce the class
> locks) does not seem to regress (at least based on benchmarking), but
> z3fold and zbud suffer. I think we are starting to pay the price of
> maintaining z3fold and zbud:
>
> 1. Future improvement to related subsystems now hurts z3fold.
> Developers/maintainers have to spend extra mental capacity to consider
> this, and users could potentially see worse performance if they select
> z3fold/zbud unknowingly.
>
> 2. Contributors are confused on where they should spend their effort
> on improving.
>
> Can we at least have a roadmap for deprecating these 2? Something
> along the line of:

100% agreed. I think we can start with z3fold given that it doesn't
offer significant advantages over zbud in my testing, and zbud is
probably more popular since it was the default zpool for a while.

Then we should be able to remove zbud as well after we take care of
the MMU dependency in zsmalloc. After that, if no new allocators show
up in a while, we can drop the zpool abstraction entirely.

Just my 2c.