linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vitaly Wool <vitalywool@gmail.com>
To: Seth Jennings <sjennings@variantweb.net>
Cc: Dan Streetman <ddstreet@ieee.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan@kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH v2] zbud: allow up to PAGE_SIZE allocations
Date: Wed, 23 Sep 2015 09:54:02 +0200	[thread overview]
Message-ID: <CAMJBoFOEYv05FZqDER9hw79re4vrc3wKwGeuL=uoGbCnwodH8Q@mail.gmail.com> (raw)
In-Reply-To: <20150923031845.GA31207@cerebellum.local.variantweb.net>

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.

> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2015-09-23  7:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-22 12:17 Vitaly Wool
2015-09-22 21:49 ` Dan Streetman
2015-09-23  8:07   ` Vitaly Wool
2015-09-23 20:59   ` Vitaly Wool
2015-09-23 22:41     ` Seth Jennings
2015-09-25  5:56       ` Vitaly Wool
2015-09-23  3:18 ` Seth Jennings
2015-09-23  7:54   ` Vitaly Wool [this message]
2015-09-23 21:57     ` Seth Jennings
2015-09-25  2:13       ` Minchan Kim
2015-09-25  8:05         ` Sergey Senozhatsky
2015-09-25  8:27           ` Vitaly Wool
2015-09-25  9:57             ` Sergey Senozhatsky
2015-09-25  8:17         ` Vitaly Wool
2015-09-25  8:47           ` Minchan Kim
2015-09-25  8:50             ` Minchan Kim
2015-09-25 10:51             ` Vitaly Wool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMJBoFOEYv05FZqDER9hw79re4vrc3wKwGeuL=uoGbCnwodH8Q@mail.gmail.com' \
    --to=vitalywool@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=ddstreet@ieee.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=sjennings@variantweb.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox