public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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;
 	}
 


  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