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

From: Vitaly Wool <vitaly.wool@konsulko.com>
To: Ananda Badmaev <a.badmaev@clicknet.pro>
Cc: Yosry Ahmed <yosryahmed@google.com>, Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH v5] mm: add zblock - new allocator for use via zpool API
Date: Thu, 29 Sep 2022 08:55:48 +0200	[thread overview]
Message-ID: <CAM4kBB+C6AR4Ng02qOwZ-yiCyqw1r=CpcW4FQS7Z_JS_ywbtmQ@mail.gmail.com> (raw)
In-Reply-To: <dedad1ba-5e87-bc24-1cd8-c25e2d8cd9cb@clicknet.pro>

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