From: Dan Streetman <ddstreet@ieee.org>
To: Vitaly Wool <vitalywool@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Minchan Kim <minchan@kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH 1/2] zbud: allow PAGE_SIZE allocations
Date: Mon, 21 Sep 2015 11:27:08 -0400 [thread overview]
Message-ID: <CALZtONA=z_NniVg9jz+vESL0QgSvLZsDU+oBkQrJRmco=Yv24g@mail.gmail.com> (raw)
In-Reply-To: <CAMJBoFNmK94yPL7GkRPyeyETn8_dC+zCvd8efEH=ncgPDyuJuQ@mail.gmail.com>
On Fri, Sep 18, 2015 at 4:03 AM, Vitaly Wool <vitalywool@gmail.com> wrote:
>> I don't know how zsmalloc handles uncompressible PAGE_SIZE allocations, but
>> I wouldn't expect it to be any more clever than this? So why duplicate the
>> functionality in zswap and zbud? This could be handled e.g. at the zpool
>> level? Or maybe just in zram, as IIRC in zswap (frontswap) it's valid just
>> to reject a page and it goes to physical swap.
zpool doesn't actually store pages anywhere; zbud and zsmalloc do the
storing, and they do it in completely different ways. Storing an
uncompressed page has to be done in zbud and zsmalloc, not zpool. And
zram can't do it either; zram doesn't actually store pages either, it
relies on zsmalloc to store all its pages.
>
> From what I can see, zsmalloc just allocates pages and puts them into
> a linked list. Using the beginning of a page for storing an internal
> struct is zbud-specific, and so is this patch.
zsmalloc has size "classes" that allow storing "objects" of a specific
size range (i.e. the last class size + 1, up to class size). the max
size class is:
#define ZS_MAX_ALLOC_SIZE PAGE_SIZE
so zsmalloc is able to store "objects" up to, and including, PAGE_SIZE.
--
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>
next prev parent reply other threads:[~2015-09-21 15:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-16 11:48 [PATCH 0/2] prepare zbud to be used by zram as underlying allocator Vitaly Wool
2015-09-16 11:50 ` [PATCH 1/2] zbud: allow PAGE_SIZE allocations Vitaly Wool
2015-09-17 13:00 ` Vlastimil Babka
2015-09-18 8:03 ` Vitaly Wool
2015-09-21 15:27 ` Dan Streetman [this message]
2015-09-21 16:17 ` Dan Streetman
2015-09-22 10:18 ` Vitaly Wool
2015-09-22 17:09 ` Dan Streetman
2015-09-16 11:53 ` [PATCH 2/2] zpool/zsmalloc/zbud: align on interfaces Vitaly Wool
2015-09-21 17:15 ` Dan Streetman
2015-09-17 1:30 ` [PATCH 0/2] prepare zbud to be used by zram as underlying allocator Sergey Senozhatsky
2015-09-17 10:26 ` Vitaly Wool
2015-09-21 4:18 ` Minchan Kim
2015-09-21 21:11 ` Vitaly Wool
2015-09-22 15:36 ` Minchan Kim
2015-09-22 16:49 ` Austin S Hemmelgarn
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='CALZtONA=z_NniVg9jz+vESL0QgSvLZsDU+oBkQrJRmco=Yv24g@mail.gmail.com' \
--to=ddstreet@ieee.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=vitalywool@gmail.com \
/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