linux-kernel - Re: [PATCH v2] mm: add zblock allocator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKEwX=Ma9phmURz5nyJm0MQrWmXGFLFBPwr8-Cx=zbc473rx9A@mail.gmail.com>
Date: Tue, 8 Apr 2025 14:11:58 -0700
From: Nhat Pham <nphamcs@...il.com>
To: Johannes Weiner <hannes@...xchg.org>
Cc: Igor Belousov <igor.b@...dev.am>, vitaly.wool@...sulko.se, linux-mm@...ck.org, 
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org, 
	Shakeel Butt <shakeel.butt@...ux.dev>, Yosry Ahmed <yosryahmed@...gle.com>
Subject: Re: [PATCH v2] mm: add zblock allocator

On Tue, Apr 8, 2025 at 12:55 PM Johannes Weiner <hannes@...xchg.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.