From: Minchan Kim <minchan@kernel.org>
To: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Dave Hansen <dave.hansen@intel.com>,
guz.fnst@cn.fujitsu.com, bcrl@kvack.org
Subject: Re: [RFC PATCH v2 0/4] mm: reclaim zbud pages on migration and compaction
Date: Mon, 12 Aug 2013 11:25:35 +0900 [thread overview]
Message-ID: <20130812022535.GA18832@bbox> (raw)
In-Reply-To: <1376043740-10576-1-git-send-email-k.kozlowski@samsung.com>
Hello,
On Fri, Aug 09, 2013 at 12:22:16PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> Currently zbud pages are not movable and they cannot be allocated from CMA
> region. These patches try to address the problem by:
The zcache, zram and GUP pages for memory-hotplug and/or CMA are
same situation.
> 1. Adding a new form of reclaim of zbud pages.
> 2. Reclaiming zbud pages during migration and compaction.
> 3. Allocating zbud pages with __GFP_RECLAIMABLE flag.
So I'd like to solve it with general approach.
Each subsystem or GUP caller who want to pin pages long time should
create own migration handler and register the page into pin-page
control subsystem like this.
driver/foo.c
int foo_migrate(struct page *page, void *private);
static struct pin_page_owner foo_migrate = {
.migrate = foo_migrate;
};
int foo_allocate()
{
struct page *newpage = alloc_pages();
set_pinned_page(newpage, &foo_migrate);
}
And in compaction.c or somewhere where want to move/reclaim the page,
general VM can ask to owner if it founds it's pinned page.
mm/compaction.c
if (PagePinned(page)) {
struct pin_page_info *info = get_page_pin_info(page);
info->migrate(page);
}
Only hurdle for that is that we should introduce a new page flag and
I believe if we all agree this approch, we can find a solution at last.
What do you think?
next prev parent reply other threads:[~2013-08-12 2:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-09 10:22 [RFC PATCH v2 0/4] mm: reclaim zbud pages on migration and compaction Krzysztof Kozlowski
2013-08-09 10:22 ` [RFC PATCH v2 1/4] zbud: use page ref counter for zbud pages Krzysztof Kozlowski
2013-08-09 10:22 ` [RFC PATCH v2 2/4] mm: split code for unusing swap entries from try_to_unuse Krzysztof Kozlowski
2013-08-09 10:22 ` [RFC PATCH v2 3/4] mm: use mapcount for identifying zbud pages Krzysztof Kozlowski
2013-08-09 10:22 ` [RFC PATCH v2 4/4] mm: reclaim zbud pages on migration and compaction Krzysztof Kozlowski
2013-08-12 2:25 ` Minchan Kim [this message]
2013-08-12 3:16 ` [RFC PATCH v2 0/4] " Benjamin LaHaise
2013-08-12 3:49 ` Minchan Kim
2013-08-12 16:48 ` Dave Hansen
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=20130812022535.GA18832@bbox \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=b.zolnierkie@samsung.com \
--cc=bcrl@kvack.org \
--cc=dave.hansen@intel.com \
--cc=guz.fnst@cn.fujitsu.com \
--cc=k.kozlowski@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=mgorman@suse.de \
--cc=sjenning@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).