28.09.2022 21:37, Yosry Ahmed пишет:
On Wed, Sep 28, 2022 at 1:06 AM ananda <a.badmaev@xxxxxxxxxxxx> wrote:From: Ananda <a.badmaev@xxxxxxxxxxxx> 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.
