Re: [PATCH 4/5] zsmalloc: Add ops fields to zs_pool to store evict handlers

[Johannes Weiner <hannes@cmpxchg.org>]

On Wed, Oct 26, 2022 at 01:06:12PM -0700, Nhat Pham wrote:
> This adds fields to zs_pool to store evict handlers for writeback,
> analogous to the zbud allocator.
> 
> Signed-off-by: Nhat Pham <nphamcs@gmail.com>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

> ---
>  mm/zsmalloc.c | 36 +++++++++++++++++++++++++++++++++++-
>  1 file changed, 35 insertions(+), 1 deletion(-)

Sort of tangential, but this patch highlights the boiler plate that is
involved in supporting multiple allocator backends.

We evaluated zswap with a variety of workloads, and found zbud and
z3fold simply not dense enough for the compression ratios we would get
at the higher end. They also seem more limited at lower compression
rates due to the space they require for the in-line metadata. With
writeback support, zsmalloc finally appears to be a superset of the
others. I believe Google in their DCs is using zsmalloc exclusively,
too. Android is using zram, which only supports zsmalloc.

Given their impact on the codebase wrt maintenance and hackability, it
begs the question zbud and z3fold are worth keeping around.

Seth, Dan, are you aware of usecases where zsmalloc would be a no go?