Re: [PATCH v2] mm: add zblock allocator

["Vitaly" <vitaly.wool@konsulko.se>]

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

Hello Johannes,

Den fredag 4 april 2025 kl. 22:03:21 +02:00, skrev Johannes Weiner <hannes@cmpxchg.org>:
> Hello Vitaly,
>
> On Fri, Apr 04, 2025 at 09:28:13PM +0200, Vitaly Wool wrote:
>> zblock is a special purpose allocator for storing compressed pages.
>> It stores integer number of compressed objects per its block. These
>> blocks consist of several physical pages (2**n, i. e. 1/2/4/8).
>>
>> With zblock, it is possible to densely arrange objects of various sizes
>> resulting in low internal fragmentation. Also this allocator tries to
>> fill incomplete blocks instead of adding new ones, in many cases
>> providing a compression ratio substantially higher than z3fold and zbud
>> (though lower than zmalloc's).
>
> Do you have zswap/zswapped meminfo metrics from these tests?

Yep, and those look somewhat similar:
- zblock:
Zswap: 234128 kB
Zswapped: 733216 kB

- zsmalloc:
Zswap: 286080 kB
Zswapped: 774688 kB

<snip>
>> Since zswap is used starting from minute 21, this gives 9% in average in
>> advantage for zblock.
>
> This might be the linker step swapping out source files that are no
> longer needed. Do you have metrics for zswpout and zswpin as well?

I don't think so, the logs show that the compilation is ongoing. Then again, we're just running out of RAM at that point.
Regarding the zswpin/zswpout, zswpin numbers are marginal with the compilation test and zswpout numbers are slightly bigger for zsmalloc (average ~50k vs ~49k).

The numbers for the stress-ng test (stress-ng --vm 4 --vm-bytes 8G --vm-keep --timeout 10m --metrics-brief) are roughly the same:

- zblock: zswpin 9870143 zswpout 10642176
- zsmalloc: zswpin 10642941 zswpout 10432625

<snip>
> My concern with this allocator, and the other alternatives to zsmalloc
> before, is the following:
>
> You might be faster at allocating objects. But if storage density is
> worse, it means you have to zswap more pages to meet the same incoming
> allocation demand. That means more object allocations and more
> compression, and often a higher rate of refaults and decompressions.

I understand. It looks like the storage density is comparable, and for 16K pages zblock may even be doing a better job, see above.

~Vitaly



[-- Attachment #2.1: Type: text/html, Size: 3060 bytes --]