lkml.org 
[lkml]   [2015]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2] zbud: allow up to PAGE_SIZE allocations
    On Wed, Sep 23, 2015 at 09:54:02AM +0200, Vitaly Wool wrote:
    > On Wed, Sep 23, 2015 at 5:18 AM, Seth Jennings <sjennings@variantweb.net> wrote:
    > > On Tue, Sep 22, 2015 at 02:17:33PM +0200, Vitaly Wool wrote:
    > >> Currently zbud is only capable of allocating not more than
    > >> PAGE_SIZE - ZHDR_SIZE_ALIGNED - CHUNK_SIZE. This is okay as
    > >> long as only zswap is using it, but other users of zbud may
    > >> (and likely will) want to allocate up to PAGE_SIZE. This patch
    > >> addresses that by skipping the creation of zbud internal
    > >> structure in the beginning of an allocated page (such pages are
    > >> then called 'headless').
    > >
    > > I guess I'm having trouble with this. If you store a PAGE_SIZE
    > > allocation in zbud, then the zpage can only have one allocation as there
    > > is no room for a buddy. Sooooo... we have an allocator for that: the
    > > page allocator.
    > >
    > > zbud doesn't support this by design because, if you are only storing one
    > > allocation per page, you don't gain anything.
    > >
    > > This functionality creates many new edge cases for the code.
    > >
    > > What is this use case you envision? I think we need to discuss
    > > whether the use case exists and if it justifies the added complexity.
    >
    > The use case is to use zram with zbud as allocator via the common
    > zpool api. Sometimes determinism and better worst-case time are more
    > important than high compression ratio.
    > As far as I can see, I'm not the only one who wants this case
    > supported in mainline.

    Ok, I can see that having the allocator backends for zpool
    have the same set of constraints is nice.

    I'll look at your latest patch.

    Thanks,
    Seth

    >
    > > We are crossing a boundary into zsmalloc style complexity with storing
    > > stuff in the struct page, something I really didn't want to do in zbud.
    >
    > Well, the thing is we need PAGE_SIZE allocations supported to use zram
    > with zbud. I can of course add the code handling this in zpool but I
    > am quite sure doing that in zbud directly is a better idea. I'm very
    > keen on keeping the complexity down as much as possible though.
    >
    > > zbud is the simple one, zsmalloc is the complex one. I'd hate to have
    > > two complex ones :-/
    >
    > Who am I to disagree :) Keeping zbud simple is my goal, too, but once
    > again, I'd really like it to support PAGE_SIZE allocations. And if it
    > doesn't, the whole zpool thing for it becomes useless, since there
    > will hardly be any zbud users other than zswap.
    >
    > ~vitaly


    \
     
     \ /
      Last update: 2015-09-24 00:01    [W:2.633 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site