Re: [PATCH v2] zbud: allow up to PAGE_SIZE allocations

[Minchan Kim]

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@xxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/