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

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

28.09.2022 21:37, Yosry Ahmed пишет:
> On Wed, Sep 28, 2022 at 1:06 AM ananda <a.badmaev@clicknet.pro> wrote:
>>
>> From: Ananda <a.badmaev@clicknet.pro>
>>
>>      Zblock stores integer number of compressed objects per zblock block.
>> 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.
>>      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.
>>      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.
>>
> 
> It seems to me, and I can be wrong, that there is some overlap in
> design and goals between this zpool backend and zsmalloc. They both
> try to avoid internal fragmentation by avoiding the static slots used
> by zbud and z3fold, and instead pack compressed pages more
> dynamically. They both have some sort of concurrency handling
> (separate block lists in zblock vs. classes in zsmalloc). A key
> difference is that zsmalloc avoids higher order allocations (at least
> based on its docs), and instead allows compressed pages to span across
> 0-order page boundaries.

You are right.

> The key differences I see here (based on this commit message and
> zsmalloc docs) are:
> a) Blocks in zblock can consist of higher order pages.
> b) Compressed pages in zsmalloc can span page boundaries (I am
> assuming this isn't the case for zblock).
> 
> It appears to me that if zblock has better performance than zsmalloc,
> it can be because pages in zblock are physically contiguous vs. the
> 0-order pages in zsmalloc (TLB misses, cache misses, etc). Is my
> assumption correct?
> 

Yes.

> If yes, would it be better to implement those changes as some tunable
> extension to zsmalloc? It would make it easier if we have overall less
> zpool backends, and also easier for current users of zsmalloc to
> experiment with these changes.
> 

Sounds reasonable, but I'm afraid in this case zsmalloc code will become 
overloaded also there might be problems with keeping zblock simplicity.