On Thu, Sep 29, 2022 at 7:25 AM Ananda Badmaev <a.badmaev@xxxxxxxxxxxx> wrote: > > 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.
