lkml.org 
[lkml]   [2015]   [Sep]   [24]   [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
Hello,

On Wed, Sep 23, 2015 at 04:57:26PM -0500, Seth Jennings wrote:
> 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.

Sorry for delay. I'm on vacation until next week.
It seems Seth was missed in previous discusstion which was not the end.

I already said questions, opinion and concerns but anything is not clear
until now. Only clear thing I could hear is just "compaction stats are
better" which is not enough for me. Sorry.

1) https://lkml.org/lkml/2015/9/15/33
2) https://lkml.org/lkml/2015/9/21/2

Vitally, Please say what's the root cause of your problem and if it
is external fragmentation, what's the problem of my approach?

1) make non-LRU page migrate
2) provide zsmalloc's migratpage

We should provide it for CMA as well as external fragmentation.
I think we could solve your issue with above approach and
it fundamentally makes zsmalloc/zbud happy in future.

Also, please keep it in mind that zram has been in linux kernel for
memory efficiency for a long time and later zswap/zbud was born
for *determinism* at the cost of memory efficiency.

Thanks.


\
 
 \ /
  Last update: 2015-09-25 04:41    [W:0.068 / U:0.944 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site