From: Andrew Morton <akpm@linux-foundation.org>
To: Shaohua Li <shaohua.li@intel.com>
Cc: nickpiggin@yahoo.com.au, clameter@sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC] some page can't be migrated
Date: Sat, 26 Jan 2008 22:03:51 -0800 [thread overview]
Message-ID: <20080126220351.a04819f9.akpm@linux-foundation.org> (raw)
In-Reply-To: <1201241005.24290.5.camel@sli10-desk.sh.intel.com>
> On Fri, 25 Jan 2008 14:03:25 +0800 Shaohua Li <shaohua.li@intel.com> wrote:
>
> - if (!page->mapping)
> + if (!page->mapping) {
> + if (!PageAnon(page) && PagePrivate(page))
> + try_to_release_page(page, GFP_KERNEL);
> goto rcu_unlock;
> + }
We call something(GFP_KERNEL) under rcu_read_lock()? I've lost track of
the myriad flavours of rcu which we purport to support, but I don't think
they'll all like us blocking under rcu_read_lock().
We _won't_ block, because try_to_release_page() will see the NULL ->mapping
and will call the non-blocking try_to_free_buffers(). But still, it looks
bad, and will cause problems if someone decides to add a might_sleep_if()
to try_to_release_page().
So... I'd suggest that it would be better to add an apologetic comment and
call direct into try_to_free_buffers().
> - * This is a corner case handling.
> - * When a new swap-cache is read into, it is linked to LRU
> + * There are corner cases handling.
> + * 1. When a new swap-cache is read into, it is linked to LRU
hm, that didn't improve the rather flakey grammar in there. Oh well.
> Acked-by: Nick Piggin <npiggin@suse.de>
> Acked-by: Christoph Lameter <clameter@sgi.com>
hm.
Please review and test....
--- a/mm/migrate.c~page-migraton-handle-orphaned-pages-fix
+++ a/mm/migrate.c
@@ -650,20 +650,28 @@ static int unmap_and_move(new_page_t get
}
/*
- * There are corner cases handling.
- * 1. When a new swap-cache is read into, it is linked to LRU
- * and treated as swapcache but has no rmap yet.
- * Calling try_to_unmap() against a page->mapping==NULL page is
- * BUG. So handle it here.
- * 2. Orphaned page (see truncate_complete_page) might have
- * fs-private metadata, the page is truncated. The page can be picked
- * up due to memory offlineing. Everywhere else except page reclaim,
- * the page is invisible to the vm, so the page can't be migrated. Try
- * to free metadata, so the page can be freed.
+ * Corner case handling:
+ * 1. When a new swap-cache page is read into, it is added to the LRU
+ * and treated as swapcache but it has no rmap yet.
+ * Calling try_to_unmap() against a page->mapping==NULL page will
+ * trigger a BUG. So handle it here.
+ * 2. An orphaned page (see truncate_complete_page) might have
+ * fs-private metadata. The page can be picked up due to memory
+ * offlining. Everywhere else except page reclaim, the page is
+ * invisible to the vm, so the page can not be migrated. So try to
+ * free the metadata, so the page can be freed.
*/
if (!page->mapping) {
- if (!PageAnon(page) && PagePrivate(page))
- try_to_release_page(page, GFP_KERNEL);
+ if (!PageAnon(page) && PagePrivate(page)) {
+ /*
+ * Go direct to try_to_free_buffers() here because
+ * a) that's what try_to_release_page() would do anyway
+ * b) we may be under rcu_read_lock() here, so we can't
+ * use GFP_KERNEL which is what try_to_release_page()
+ * needs to be effective.
+ */
+ try_to_release_buffers(page);
+ }
goto rcu_unlock;
}
next prev parent reply other threads:[~2008-01-27 6:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-23 6:22 [RFC] some page can't be migrated Shaohua Li
2008-01-25 3:03 ` Nick Piggin
2008-01-25 3:09 ` Christoph Lameter
2008-01-25 3:09 ` Shaohua Li
2008-01-25 3:12 ` Christoph Lameter
2008-01-25 3:18 ` Shaohua Li
2008-01-25 5:20 ` Nick Piggin
2008-01-25 3:37 ` Christoph Lameter
2008-01-25 3:59 ` Shaohua Li
2008-01-25 4:01 ` Christoph Lameter
2008-01-25 4:17 ` Nick Piggin
2008-01-25 4:42 ` Christoph Lameter
2008-01-25 6:03 ` Shaohua Li
2008-01-27 6:03 ` Andrew Morton [this message]
2008-01-28 1:43 ` Nick Piggin
2008-01-28 1:48 ` Shaohua Li
2008-01-28 19:09 ` Christoph Lameter
2008-01-28 23:17 ` Christoph Lameter
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=20080126220351.a04819f9.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=shaohua.li@intel.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