[RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED

[Yosry Ahmed]

On Tue, Jan 16, 2024 at 7:39 AM Christoph Hellwig <hch at infradead.org> wrote:
>
> On Fri, Jan 12, 2024 at 04:38:30PM -0800, Nhat Pham wrote:
> > >
> > > I thought deprecating z3fold is the low hanging fruit. Then, once we
> > > can sort out the MMU dependency in zsmalloc, we can go after zbud as
> > > well.
> >
> > Makes sense to me. Should we do the same thing to zbud? We probably
> > have even less of a case for it, no?
>
> Is there any user visible effect of switching the allocator?  If not it
> seems a bit pointless to deprecate them vs just removing them (or maybe
> making z3fold depend on !MMU for now).

Well, better compression ratios for one :)

I think a long time ago there were complaints that zsmalloc had higher
latency than zbud/z3fold, but since then a lot of things have changed
(including nice compaction optimization from Sergey, and compaction
was one of the main factors AFAICT). Also, recent experiments that
Chris Li conducted showed that (at least in our setup), the
decompression is only a small part of the fault latency with zswap
(i.e. not the main factor) -- so I am not sure if it actually matters
in practice.

That said, I have not conducted any experiments personally with z3fold
or zbud, which is why I proposed the conservative approach of marking
as deprecated first. However, if others believe this is unnecessary I
am fine with removal as well. Whatever we agree on is fine by me.