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: <6e1c6b20481c2cb41930d37da4fe8aeb@beldev.am>
Date: Wed, 09 Apr 2025 21:59:58 +0400
From: Igor Belousov <igor.b@...dev.am>
To: Johannes Weiner <hannes@...xchg.org>
Cc: Nhat Pham <nphamcs@...il.com>, 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

Hi Johannes,

>> Sure. zstd/8 cores/make -j32:
>> 
>> zsmalloc:
>> real	7m36.413s
>> user	38m0.481s
>> sys	7m19.108s
>> Zswap:            211028 kB
>> Zswapped:         925904 kB
>> zswpin 397851
>> zswpout 1625707
>> zswpwb 5126
>> 
>> zblock:
>> real	7m55.009s
>> user	39m23.147s
>> sys	7m44.004s
>> Zswap:            253068 kB
>> Zswapped:         919956 kB
>> zswpin 456843
>> zswpout 2058963
>> zswpwb 3921
> 
> 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
> *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.

Actually there's a slight bug in zblock code for 4K page case which 
caused storage inefficiency for small (== well compressed) memory 
blocks. With that one fixed, the results look a lot brighter for zblock:

1. zblock/zstd/8 cores/make -j32 bzImage
real	7m28.290s
user	37m27.055s
sys	7m18.629s
Zswap:            221516 kB
Zswapped:         904104 kB
zswpin 425424
zswpout 2011503
zswpwb 4111

2a. zblock/zstd/16 cores/make -j16 modules
real	15m53.119s
user	199m45.722s
sys	36m21.544s
zswpin 26600
zswpout 287021
zswpwb 0
Zswap:            205908 kB
Zswapped:         858516 kB

2b. zsmalloc/zstd/16 cores/make -j16 modules
real	16m31.052s
user	207m3.612s
sys	37m49.891s
zswpin 27044
zswpout 296763
zswpwb 61
Zswap:            198740 kB
Zswapped:         868020 kB

So what we see is:
* on 4K pages, zblock matches zsmalloc with regard to storage density on 
longer tests and gives better performance in virtually all scenarios
* on 16K pages, zblock is superior to zsmalloc in terms of both 
performance and storage density.

> 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.

Given the above, I sincerely hope that you reconsider.

Thanks,
Igor