linux-kernel - Re: [PATCH v4] 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: <uducoj43wg46d756fxbgdwsnql4kff5if6psuly75qfimk44yg@vbu3cf2ealjn>
Date: Fri, 2 May 2025 08:43:22 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Vitaly Wool <vitaly.wool@...sulko.se>
Cc: Yosry Ahmed <yosry.ahmed@...ux.dev>, linux-mm@...ck.org, 
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org, Nhat Pham <nphamcs@...il.com>, 
	Shakeel Butt <shakeel.butt@...ux.dev>, Johannes Weiner <hannes@...xchg.org>, 
	Igor Belousov <igor.b@...dev.am>, Minchan Kim <minchan@...nel.org>, 
	Sergey Senozhatsky <senozhatsky@...omium.org>
Subject: Re: [PATCH v4] mm: add zblock allocator

On (25/05/01 14:41), Vitaly Wool wrote:
[..]
> Bottom line, ending up with a lot of blocks each containing a single object
> is not a real life scenario.

Why not?  What if the data patterns do not favor compressible objects?
E.g. what if the distribution of compressed objects looks like this (a real
zsmalloc stats):

size-class   objs-allocated
---------------------------
...
1904         3315
1920         3468
1936         3515
2048         25816
2144         22363
2160         3230
2176         3075
2192         2990
2224         5665
2272         8118
2304         5040
2336         4529
2384         6132
2400         1768
2448         4825
2512         5135
2560         2944
2592         1562
2624         1512
2720         3813
2832         3315
2864         820
...

Notice tenth of thousands of 2048-2144 bytes objects.  zsmalloc size
classes are fundamentally independent of each other and, hence, of
the compressed objects distribution: the lack of objects, or even
"the absence of" for that matter, in size-class 256 does not change
a thing for size-class 2048.  This is a very important property.