Received-SPF: pass (google.com: domain of linux-kernel+bounces-77245-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Thu, 22 Feb 2024 19:20:28 +0000
In-Reply-To: <CAKEwX=MELnV5uzMg2sR0iLd9jiwe-Z9sTh1dhDRiescrDce5rA@mail.gmail.com>
Precedence: bulk
Mime-Version: 1.0
References: <CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com>
 <CAKEwX=MELnV5uzMg2sR0iLd9jiwe-Z9sTh1dhDRiescrDce5rA@mail.gmail.com>
Message-ID: <ZdeefPytg81oXVAc@google.com>
Subject: Re: [RFC] Analyzing zpool allocators / Removing zbud and z3fold
From: Yosry Ahmed <yosryahmed@google.com>
To: Nhat Pham <nphamcs@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, Vitaly Wool <vitaly.wool@konsulko.com>, 
	Miaohe Lin <linmiaohe@huawei.com>, Johannes Weiner <hannes@cmpxchg.org>, Linux-MM <linux-mm@kvack.org>, 
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Christoph Hellwig <hch@infradead.org>, 
	Sergey Senozhatsky <senozhatsky@chromium.org>, Minchan Kim <minchan@kernel.org>, 
	Chris Down <chris@chrisdown.name>, Seth Jennings <sjenning@redhat.com>, 
	Dan Streetman <ddstreet@ieee.org>, Chris Li <chrisl@kernel.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 22, 2024 at 01:23:43PM +0700, Nhat Pham wrote:
> On Fri, Feb 9, 2024 at 10:27=E2=80=AFAM Yosry Ahmed <yosryahmed@google.co=
m> wrote:
> >
> > I did not perform any sophisticated analysis on these histograms, but
> > eyeballing them makes it clear that all allocators have somewhat
> > similar latencies. zbud is slightly better than zsmalloc, and z3fold
> > is slightly worse than zsmalloc. This corresponds naturally to the
> > build times in (a).
> >
> > (c) Maximum size of the zswap pool
> >
> > *** zsmalloc ***
> > 1,137,659,904 bytes =3D ~1.13G
> >
> > *** zbud ***
> > 1,535,741,952 bytes =3D ~1.5G
> >
> > *** z3fold ***
> > 1,151,303,680 bytes =3D ~1.15G
> >
> > zbud consumes ~32.7% more memory, and z3fold consumes ~1.8% more
> > memory. This makes sense because zbud only stores a maximum of two
> > compressed pages on each order-0 page, regardless of the compression
> > ratio, so it is bound to consume more memory.
> >
> > -------------------------------- </Results> ---------------------------=
-----
> >
> > According to those results, it seems like zsmalloc is superior to
> > z3fold in both efficiency and latency. Zbud has a small latency
> > advantage, but that comes with a huge cost in terms of memory
> > consumption. Moreover, most known users of zswap are currently using
> > zsmalloc. Perhaps some folks are using zbud because it was the default
> > allocator up until recently. The only known disadvantage of zsmalloc
> > is the dependency on MMU.
> >
> > Based on that, I think it doesn't make sense to keep all 3 allocators
> > going forward. I believe we should start with removing either zbud or
> > z3fold, leaving only one allocator supporting MMU. Once zsmalloc
> > supports !MMU (if possible), we can keep zsmalloc as the only
> > allocator.
> >
> > Thoughts and feedback are highly appreciated. I tried to CC all the
> > interested folks, but others feel free to chime in.
>=20
> I already voiced my opinion on the other thread, but to reiterate, my
> vote is towards deprecating/removing z3fold :)
> Unless someone can present a convincing argument/use case/workload,
> where z3fold outshines both zbud and zsmalloc, or at least is another
> point on the Pareto front of (latency x memory saving).

I can re-send the RFC to mark z3fold as deprecated with a reference to
the data here or a quote to some of it. Alternatively, we can remove the
code directly if we believe there are no users.

There were some conflicting opinions last time and I was hoping we can
settle them.

I am also low key hoping Andrew would chime in at some point with what
he prefers (deprecate, remove, or leave as-is).