From: David Rientjes <rientjes@google.com>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Paul Jackson <pj@sgi.com>,
kosaki.motohiro@jp.fujitsu.com, andi@firstfloor.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, clameter@sgi.com, mel@csn.ul.ie
Subject: Re: [2.6.24-rc8-mm1][regression?] numactl --interleave=all doesn't works on memoryless node.
Date: Tue, 5 Feb 2008 14:44:33 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.1.00.0802051437050.9587@chino.kir.corp.google.com> (raw)
In-Reply-To: <1202249070.5332.58.camel@localhost>
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
> The patch I just posted doesn't depend on the numactl changes and seems
> quite minimal to me. I think it cleans up the differences between
> set_mempolicy() and mbind(), as well. However, some may take exception
> to the change in behavior--silently ignoring dis-allowed nodes in
> set_mempolicy().
>
If the intent of the set_mempolicy() call is going to be preserved in the
struct mempolicy with Paul's change, then we're going to allow disallowed
nodes anyway. So the only nodemask errors that we should return are ones
that are empty; nodemasks that include offlined nodes should be allowed to
support node hotplug. Likewise, memoryless nodes should still be saved as
the intent of the syscall.
The change to save the intent or silently ignore disallowed nodes would
also require applications to issue a successive get_mempolicy() call to
know what their current mempolicy is, since it will be able to change with
a cpusets change or node hotplug event. There is no longer this assurance
that if set_mempolicy() returns without an error that the memory policy is
effected. But in the presence of subsystems such as cpusets that allow
those mempolicies to change from beneath the application, there is no way
around that: the nodemask that the mempolicy acts on can dynamically
change at any time.
So I don't see any problem with silently ignoring disallowed nodes and
encourage it so that the kernel accomodates the intent of the mempolicy in
the future if and when it can be effected.
David
--
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:[~2008-02-05 22:44 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-02 8:12 KOSAKI Motohiro
2008-02-02 9:09 ` Andi Kleen
2008-02-02 9:37 ` KOSAKI Motohiro
2008-02-02 11:30 ` Andi Kleen
2008-02-04 19:03 ` Christoph Lameter
2008-02-04 18:20 ` Lee Schermerhorn
2008-02-05 9:26 ` [2.6.24 regression][BUGFIX] " KOSAKI Motohiro
2008-02-08 19:45 ` [PATCH 2.6.24-mm1] Mempolicy: silently restrict nodemask to allowed nodes V3 Lee Schermerhorn
2008-02-09 18:11 ` KOSAKI Motohiro
2008-02-10 5:29 ` KOSAKI Motohiro
2008-02-10 5:49 ` Greg KH
2008-02-10 7:42 ` Linus Torvalds
2008-02-10 10:31 ` Andrew Morton
2008-02-11 16:47 ` Lee Schermerhorn
2008-02-12 0:43 ` KOSAKI Motohiro
2008-02-12 1:00 ` David Rientjes
2008-02-12 1:56 ` KOSAKI Motohiro
2008-02-12 2:05 ` David Rientjes
2008-02-12 3:05 ` KOSAKI Motohiro
2008-02-12 3:17 ` David Rientjes
2008-02-12 15:08 ` Lee Schermerhorn
2008-02-12 19:06 ` David Rientjes
2008-02-13 0:07 ` Lee Schermerhorn
2008-02-13 0:42 ` David Rientjes
2008-02-13 16:32 ` Lee Schermerhorn
2008-02-13 18:32 ` David Rientjes
2008-02-13 18:56 ` Lee Schermerhorn
2008-02-12 4:30 ` [PATCH for 2.6.24][regression fix] " KOSAKI Motohiro
2008-02-12 5:06 ` David Rientjes
2008-02-12 5:07 ` Andrew Morton
2008-02-12 13:18 ` KOSAKI Motohiro
2008-02-05 10:17 ` [2.6.24-rc8-mm1][regression?] numactl --interleave=all doesn't works on memoryless node Paul Jackson
2008-02-05 11:14 ` KOSAKI Motohiro
2008-02-05 19:56 ` David Rientjes
2008-02-05 20:51 ` Paul Jackson
2008-02-05 21:03 ` David Rientjes
2008-02-05 21:33 ` Paul Jackson
2008-02-05 22:04 ` Lee Schermerhorn
2008-02-05 22:44 ` David Rientjes [this message]
2008-02-05 22:50 ` Paul Jackson
2008-02-05 14:31 ` Mel Gorman
2008-02-05 15:23 ` Lee Schermerhorn
2008-02-05 18:12 ` Christoph Lameter
2008-02-05 18:27 ` Lee Schermerhorn
2008-02-05 19:04 ` Christoph Lameter
2008-02-05 19:15 ` Paul Jackson
2008-02-05 20:06 ` David Rientjes
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=alpine.DEB.1.00.0802051437050.9587@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=Lee.Schermerhorn@hp.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=clameter@sgi.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=pj@sgi.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