linux-kernel - Re: [PATCH v2] zbud: allow up to PAGE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Sep 2015 09:54:02 +0200
From:	Vitaly Wool <vitalywool@...il.com>
To:	Seth Jennings <sjennings@...iantweb.net>
Cc:	Dan Streetman <ddstreet@...e.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Minchan Kim <minchan@...nel.org>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH v2] zbud: allow up to PAGE_SIZE allocations

On Wed, Sep 23, 2015 at 5:18 AM, Seth Jennings <sjennings@...iantweb.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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/