Re: [PATCH v2] mm: add zblock allocator

[Johannes Weiner]

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?

> 1.1 zblock
> 
> real    25m53.040s
> user    96m43.424s
> sys     4m56.652s
> 
> real    25m20.748s
> user    94m24.324s
> sys     4m58.005s
> 
> real    25m37.486s
> user    95m35.913s
> sys     4m55.892s
> 
> 1.2 zsmalloc
> 
> real    26m17.934s
> user    97m13.342s
> sys     5m2.415s
> 
> real    25m50.694s
> user    95m22.065s
> sys     5m1.305s
> 
> real    25m57.714s
> user    96m14.675s
> sys     4m59.081s
> 
> 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?

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 would assume you're at least zswapping out more to make room for
whatever happens at 21 minutes. This doesn't seem to hurt the time,
which is promising and highlights how much faster zblock is.

But for the full picture, it would be good to see the reuse/zswpin
rates, especially in the context of overall swap activity.

And if there is no notable swapin rate, maybe test without tmpfs and
tune the memory allowance to force at least some degree of reuse.