From: Dan Streetman <ddstreet@ieee.org>
To: Seth Jennings <sjennings@variantweb.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Heesub Shin <heesub.shin@samsung.com>,
Nitin Gupta <ngupta@vflare.org>, Linux-MM <linux-mm@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Sunae Seo <sunae.seo@samsung.com>
Subject: Re: [RFC PATCH 0/9] mm/zbud: support highmem pages
Date: Thu, 23 Oct 2014 19:14:15 -0400 [thread overview]
Message-ID: <CALZtONCn8R0v7WV+fhMBh=y9b=ES0GuM9ds6TBtYeyKR-Z7LxA@mail.gmail.com> (raw)
In-Reply-To: <1413287968-13940-1-git-send-email-heesub.shin@samsung.com>
On Tue, Oct 14, 2014 at 7:59 AM, Heesub Shin <heesub.shin@samsung.com> wrote:
> zbud is a memory allocator for storing compressed data pages. It keeps
> two data objects of arbitrary size on a single page. This simple design
> provides very deterministic behavior on reclamation, which is one of
> reasons why zswap selected zbud as a default allocator over zsmalloc.
>
> Unlike zsmalloc, however, zbud does not support highmem. This is
> problomatic especially on 32-bit machines having relatively small
> lowmem. Compressing anonymous pages from highmem and storing them into
> lowmem could eat up lowmem spaces.
>
> This limitation is due to the fact that zbud manages its internal data
> structures on zbud_header which is kept in the head of zbud_page. For
> example, zbud_pages are tracked by several lists and have some status
> information, which are being referenced at any time by the kernel. Thus,
> zbud_pages should be allocated on a memory region directly mapped,
> lowmem.
>
> After some digging out, I found that internal data structures of zbud
> can be kept in the struct page, the same way as zsmalloc does. So, this
> series moves out all fields in zbud_header to struct page. Though it
> alters quite a lot, it does not add any functional differences except
> highmem support. I am afraid that this kind of modification abusing
> several fields in struct page would be ok.
Seth, have you had a chance to review this yet? I'm going to try to
take a look at it next week if you haven't yet. Letting zbud use
highmem would be a good thing.
>
> Heesub Shin (9):
> mm/zbud: tidy up a bit
> mm/zbud: remove buddied list from zbud_pool
> mm/zbud: remove lru from zbud_header
> mm/zbud: remove first|last_chunks from zbud_header
> mm/zbud: encode zbud handle using struct page
> mm/zbud: remove list_head for buddied list from zbud_header
> mm/zbud: drop zbud_header
> mm/zbud: allow clients to use highmem pages
> mm/zswap: use highmem pages for compressed pool
>
> mm/zbud.c | 244 ++++++++++++++++++++++++++++++-------------------------------
> mm/zswap.c | 4 +-
> 2 files changed, 121 insertions(+), 127 deletions(-)
>
> --
> 1.9.1
>
--
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:[~2014-10-23 23:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-14 11:59 Heesub Shin
2014-10-14 11:59 ` [RFC PATCH 1/9] mm/zbud: tidy up a bit Heesub Shin
2014-10-14 11:59 ` [RFC PATCH 2/9] mm/zbud: remove buddied list from zbud_pool Heesub Shin
2014-10-14 11:59 ` [RFC PATCH 3/9] mm/zbud: remove lru from zbud_header Heesub Shin
2014-10-14 11:59 ` [RFC PATCH 4/9] mm/zbud: remove first|last_chunks " Heesub Shin
2014-10-14 11:59 ` [RFC PATCH 5/9] mm/zbud: encode zbud handle using struct page Heesub Shin
2014-10-14 11:59 ` [RFC PATCH 6/9] mm/zbud: remove list_head for buddied list from zbud_header Heesub Shin
2014-10-14 11:59 ` [RFC PATCH 7/9] mm/zbud: drop zbud_header Heesub Shin
2014-10-14 11:59 ` [RFC PATCH 8/9] mm/zbud: allow clients to use highmem pages Heesub Shin
2014-10-14 11:59 ` [RFC PATCH 9/9] mm/zswap: use highmem pages for compressed pool Heesub Shin
2014-10-23 23:14 ` Dan Streetman [this message]
2014-10-24 15:27 ` [RFC PATCH 0/9] mm/zbud: support highmem pages Seth Jennings
2014-11-04 16:33 ` Seth Jennings
2015-01-27 20:24 ` Seth Jennings
2015-01-28 7:14 ` Heesub Shin
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='CALZtONCn8R0v7WV+fhMBh=y9b=ES0GuM9ds6TBtYeyKR-Z7LxA@mail.gmail.com' \
--to=ddstreet@ieee.org \
--cc=akpm@linux-foundation.org \
--cc=heesub.shin@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ngupta@vflare.org \
--cc=sjennings@variantweb.net \
--cc=sunae.seo@samsung.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