Re: [PATCH v6] mm: add zblock - new allocator for use via zpool API

[Ananda Badmaev <a.badmaev@clicknet.pro>]

28.11.2022 23:01, Johannes Weiner пишет:
> On Fri, Nov 04, 2022 at 11:58:56AM +0300, ananda wrote:
>> From: Ananda <a.badmaev@clicknet.pro>
>>
>>      Zblock stores integer number of compressed objects per zblock block.
> 
> What does that mean?
> 

The general idea is to store an integer number of compressed pages in a 
fixed-size storage unit. In case of zbud and z3fold single pages act as 
this storage unit. In zblock, storage units can consist of several pages 
(page order 0, 1, 2 or 3), but still their size is set at compile time 
and does not change further.

>> These blocks consist of several physical pages (1/2/4/8) and are arranged
>> in linked lists.
>>      The range from 0 to PAGE_SIZE is divided into the number of intervals
>> corresponding to the number of lists and each list only operates objects
>> of size from its interval. Thus the block lists are isolated from each
>> other, which makes it possible to simultaneously perform actions with
>> several objects from different lists.
> 
> This was benchmarked not long ago in the context of zsmalloc, and it
> didn't seem to matter too much in real world applications:
> 
> https://lore.kernel.org/linux-mm/20221107213114.916231-1-nphamcs@gmail.com/
> 
> Do you have situations where this matters?
> 

It seems that in real applications, compression ratio mainly matters. 
According to my estimates, speed of allocator operations does not 
particularly contribute to overall performance compared to compression time.


>>      Blocks make it 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 thus in many cases providing
>> a compression ratio substantially higher than z3fold and zbud.
> 
> How does it compare to zsmalloc?
> 
In general case:
Zsmalloc > zsblock > z3fold > zbud

>>      Zblock does not require MMU and also is superior to zsmalloc with
>> regard to the worst execution times, thus allowing for better response time
>> and real-time characteristics of the whole system.
> 
> zsmalloc has depends on MMU, but which parts actually require it? It
> has its own handle indirection and can migrate objects around and
> replace backing pages without any virtual memory tricks. There is the
> kmap stuff of course, because it supports highmem backing pages, but
> that isn't relevant on NOMMU either.
> 
> Also can you please elaborate on the worst execution time?
> 

There is an opinion that use of zsmalloc can lead to an increase in 
response time. And zblock should have better real-time metrics.

> My first impression is that this looks awfully close to zsmalloc, with
> a couple fewer features and somewhat more static design choices. It's
> in that sense reminiscent of the slob allocator, which we're in the
> process of removing, because 3 slab allocators is a pain to
> maintain. This would be the 4th zswap allocator, and it's not clear
> that it's drastically outperforming or doing something that isn't
> possible in one of the existing ones.

Initially there was an attempt to combine advantages of zbud and 
zsmalloc to obtain a fairly simple and fast allocator but with a 
compression ratio closer to zsmalloc.