Re: [PATCH v2] mm: add zblock allocator

[Nhat Pham <nphamcs@gmail.com>]

On Tue, Apr 8, 2025 at 12:55 PM Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> On Tue, Apr 08, 2025 at 01:20:11PM +0400, Igor Belousov wrote:
>
> So zstd results in nearly double the compression ratio, which in turn
> cuts total execution time *almost in half*.
>
> The numbers speak for themselves. Compression efficiency >>> allocator
> speed, because compression efficiency ultimately drives the continuous

Yeah good compression ratio == better performance, assuming we have an
allocator that can ensure a good enough storage density to take
advantage of the compression ratio. I think the experiments show that.

We don't need the no-MMU upstream-speaking, so with this I struggle to
see the point of inclusion of this new allocator.

> *rate* at which allocations need to occur. You're trying to optimize a
> constant coefficient at the expense of a higher-order one, which is a
> losing proposition.
>
> This is a general NAK from me on any new allocators that cannot match
> or outdo zsmalloc storage density in common scenarios. I'm sorry, but
> I really don't see any reason to do this.

I'll wait for Igor's and Vitaly's response, but this is a preliminary
NAK from me too, I suppose.

>
> We also should probably make zstd the zswap default.

Agree.