From: Andrew Morton <akpm@linux-foundation.org>
To: David Rientjes <rientjes@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [patch 3.5-rc3] mm, mempolicy: fix mbind() to do synchronous migration
Date: Thu, 21 Jun 2012 16:46:06 -0700 [thread overview]
Message-ID: <20120621164606.4ae1a71d.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1206201758500.3068@chino.kir.corp.google.com>
On Wed, 20 Jun 2012 18:00:12 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:
> If the range passed to mbind() is not allocated on nodes set in the
> nodemask, it migrates the pages to respect the constraint.
>
> The final formal of migrate_pages() is a mode of type enum migrate_mode,
> not a boolean. do_mbind() is currently passing "true" which is the
> equivalent of MIGRATE_SYNC_LIGHT. This should instead be MIGRATE_SYNC
> for synchronous page migration.
>
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
> mm/mempolicy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -1177,7 +1177,7 @@ static long do_mbind(unsigned long start, unsigned long len,
> if (!list_empty(&pagelist)) {
> nr_failed = migrate_pages(&pagelist, new_vma_page,
> (unsigned long)vma,
> - false, true);
> + false, MIGRATE_SYNC);
> if (nr_failed)
> putback_lru_pages(&pagelist);
> }
I can't really do anything with this patch - it's a bug added by
Peter's "mm/mpol: Simplify do_mbind()" and added to linux-next via one
of Ingo's trees.
And I can't cleanly take the patch over as it's all bound up with the
other changes for sched/numa balancing.
Is that patchset actually going anywhere in the short term in its
present form? If not, methinks it would be better to pull it out of
-next for now.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: David Rientjes <rientjes@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [patch 3.5-rc3] mm, mempolicy: fix mbind() to do synchronous migration
Date: Thu, 21 Jun 2012 16:46:06 -0700 [thread overview]
Message-ID: <20120621164606.4ae1a71d.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1206201758500.3068@chino.kir.corp.google.com>
On Wed, 20 Jun 2012 18:00:12 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:
> If the range passed to mbind() is not allocated on nodes set in the
> nodemask, it migrates the pages to respect the constraint.
>
> The final formal of migrate_pages() is a mode of type enum migrate_mode,
> not a boolean. do_mbind() is currently passing "true" which is the
> equivalent of MIGRATE_SYNC_LIGHT. This should instead be MIGRATE_SYNC
> for synchronous page migration.
>
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
> mm/mempolicy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -1177,7 +1177,7 @@ static long do_mbind(unsigned long start, unsigned long len,
> if (!list_empty(&pagelist)) {
> nr_failed = migrate_pages(&pagelist, new_vma_page,
> (unsigned long)vma,
> - false, true);
> + false, MIGRATE_SYNC);
> if (nr_failed)
> putback_lru_pages(&pagelist);
> }
I can't really do anything with this patch - it's a bug added by
Peter's "mm/mpol: Simplify do_mbind()" and added to linux-next via one
of Ingo's trees.
And I can't cleanly take the patch over as it's all bound up with the
other changes for sched/numa balancing.
Is that patchset actually going anywhere in the short term in its
present form? If not, methinks it would be better to pull it out of
-next for now.
next prev parent reply other threads:[~2012-06-21 23:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-21 1:00 [patch 3.5-rc3] mm, mempolicy: fix mbind() to do synchronous migration David Rientjes
2012-06-21 1:00 ` David Rientjes
2012-06-21 12:42 ` Mel Gorman
2012-06-21 12:42 ` Mel Gorman
2012-06-21 23:46 ` Andrew Morton [this message]
2012-06-21 23:46 ` Andrew Morton
2012-06-22 0:46 ` Linus Torvalds
2012-06-22 0:46 ` Linus Torvalds
2012-06-22 1:45 ` Andrew Morton
2012-06-22 1:45 ` Andrew Morton
2012-06-22 2:22 ` Linus Torvalds
2012-06-22 2:22 ` Linus Torvalds
2012-06-22 3:33 ` Linus Torvalds
2012-06-22 3:33 ` Linus Torvalds
2012-06-22 3:59 ` Linus Torvalds
2012-06-22 3:59 ` Linus Torvalds
2012-06-22 7:12 ` Ingo Molnar
2012-06-22 7:12 ` Ingo Molnar
2012-06-22 7:41 ` Ingo Molnar
2012-06-22 7:41 ` Ingo Molnar
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=20120621164606.4ae1a71d.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mingo@elte.hu \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.