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@xxxxxxxxx> Acked-by: Johannes Weiner <hannes@xxxxxxxxxxx> > --- > 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?
