From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: David Rientjes <rientjes@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH 2.6.24-mm1] Mempolicy: silently restrict nodemask to allowed nodes V3
Date: Tue, 12 Feb 2008 17:07:20 -0700 [thread overview]
Message-ID: <1202861240.4974.25.camel@localhost> (raw)
In-Reply-To: <alpine.DEB.1.00.0802121100211.9649@chino.kir.corp.google.com>
On Tue, 2008-02-12 at 11:06 -0800, David Rientjes wrote:
> On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
>
> > Firstly, because this was the original API.
> >
> > Secondly, I consider this key to extensible API design. Perhaps,
> > someday, we might want to assign some semantic to certain non-empty
> > nodemasks to MPOL_DEFAULT. If we're allowing applications to pass
> > arbitrary nodemask now, and just ignoring them, that becomes difficult.
> > Just like dis-allowing unassigned flag values.
> >
>
> I allow it with my patchset because there's simply no reason not to.
I'm interpreting this as "because I [David] simply see no reason not
to."
>
> MPOL_DEFAULT is the default system-wide policy that does not require a
> nodemask as a parameter. Both the man page (set_mempolicy(2)) and the
> documentation (Documentation/vm/numa_memory_policy.txt) state that.
>
> It makes no sense in the future to assign a meaning to a nodemask passed
> along with MPOL_DEFAULT. None at all.
Again, you're stating an opinion, to which you're entitled, or
expressing a limitation to your clairvoyance, for which I can't fault
you. Indeed, I tend to agree with you on this particular point--my own
opinion and/or lack of vision. However, I've been burned in the past by
just this scenario--wanting to assign meaning to something that was
ignored--because it could break existing applications. So, on general
principle, I like to be fairly strict with argument checking [despite my
natural libertarian tendencies].
> The policy is simply the
> equivalent of default_policy and, as the system default, a nodemask
> parameter to the system default policy is wrong be definition.
>
> So, logically, we can either allow all nodemasks to be passed with a
> MPOL_DEFAULT policy or none at all (it must be NULL). Empty nodemasks
> don't have any logical relationship with MPOL_DEFAULT.
Ah, maybe this explains our disconnect. Internally, a NULL nodemask
pointer specified by the application is equivalent to an empty nodemask
is equivalent to maxnode == 0. See get_nodes(). By the time
mpol_check_policy() or mpol_new() get called, all they have is a pointer
to the cleared nodemask in the stack frame of sys_set_mempolicy() or
sys_mbind(). So, the existing code's error checking doesn't require one
to specify a non-NULL, but empty nodemask. It just requires that one
does not specify any nodes with MPOL_DEFAULT.
Does this help clarify things?
Lee
P.S.,
I've had time to review the patches and have comments queued up. I'll
send along comments shortly [wherein I do mention my preference for the
error checking].
--
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-13 0:07 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-02 8:12 [2.6.24-rc8-mm1][regression?] numactl --interleave=all doesn't works on memoryless node KOSAKI Motohiro
2008-02-02 8:12 ` KOSAKI Motohiro
2008-02-02 9:09 ` Andi Kleen
2008-02-02 9:09 ` Andi Kleen
2008-02-02 9:37 ` KOSAKI Motohiro
2008-02-02 9:37 ` KOSAKI Motohiro
2008-02-02 11:30 ` Andi Kleen
2008-02-02 11:30 ` Andi Kleen
2008-02-04 19:03 ` Christoph Lameter
2008-02-04 19:03 ` Christoph Lameter
2008-02-04 18:20 ` Lee Schermerhorn
2008-02-04 18:20 ` Lee Schermerhorn
2008-02-05 9:26 ` [2.6.24 regression][BUGFIX] " KOSAKI Motohiro
2008-02-05 9:26 ` KOSAKI Motohiro
2008-02-05 21:57 ` Lee Schermerhorn
2008-02-05 22:12 ` Christoph Lameter
2008-02-06 16:00 ` Lee Schermerhorn
2008-02-05 22:15 ` Paul Jackson
2008-02-06 2:17 ` David Rientjes
2008-02-06 16:11 ` Lee Schermerhorn
2008-02-06 6:49 ` KOSAKI Motohiro
2008-02-06 17:38 ` Lee Schermerhorn
2008-02-07 8:31 ` KOSAKI Motohiro
2008-02-08 19:45 ` [PATCH 2.6.24-mm1] Mempolicy: silently restrict nodemask to allowed nodes V3 Lee Schermerhorn
2008-02-08 19:45 ` Lee Schermerhorn
2008-02-09 18:11 ` KOSAKI Motohiro
2008-02-09 18:11 ` KOSAKI Motohiro
2008-02-10 5:29 ` KOSAKI Motohiro
2008-02-10 5:29 ` KOSAKI Motohiro
2008-02-10 5:49 ` Greg KH
2008-02-10 5:49 ` Greg KH
2008-02-10 7:42 ` Linus Torvalds
2008-02-10 7:42 ` Linus Torvalds
2008-02-10 10:31 ` Andrew Morton
2008-02-10 10:31 ` Andrew Morton
2008-02-11 16:47 ` Lee Schermerhorn
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 [this message]
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 4:30 ` KOSAKI Motohiro
2008-02-12 5:06 ` David Rientjes
2008-02-12 5:06 ` David Rientjes
2008-02-12 5:07 ` Andrew Morton
2008-02-12 5:07 ` Andrew Morton
2008-02-12 13:18 ` KOSAKI Motohiro
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 10:17 ` Paul Jackson
2008-02-05 11:14 ` KOSAKI Motohiro
2008-02-05 11:14 ` KOSAKI Motohiro
2008-02-05 19:56 ` David Rientjes
2008-02-05 19:56 ` David Rientjes
2008-02-05 20:51 ` Paul Jackson
2008-02-05 20:51 ` Paul Jackson
2008-02-05 21:03 ` David Rientjes
2008-02-05 21:03 ` David Rientjes
2008-02-05 21:33 ` Paul Jackson
2008-02-05 21:33 ` Paul Jackson
2008-02-05 22:04 ` Lee Schermerhorn
2008-02-05 22:04 ` Lee Schermerhorn
2008-02-05 22:44 ` David Rientjes
2008-02-05 22:44 ` David Rientjes
2008-02-05 22:50 ` Paul Jackson
2008-02-05 22:50 ` Paul Jackson
2008-02-05 14:31 ` Mel Gorman
2008-02-05 14:31 ` Mel Gorman
2008-02-05 15:23 ` Lee Schermerhorn
2008-02-05 15:23 ` Lee Schermerhorn
2008-02-05 18:12 ` Christoph Lameter
2008-02-05 18:12 ` Christoph Lameter
2008-02-05 18:27 ` Lee Schermerhorn
2008-02-05 18:27 ` Lee Schermerhorn
2008-02-05 19:04 ` Christoph Lameter
2008-02-05 19:04 ` Christoph Lameter
2008-02-05 19:15 ` Paul Jackson
2008-02-05 19:15 ` Paul Jackson
2008-02-05 20:06 ` David Rientjes
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=1202861240.4974.25.camel@localhost \
--to=lee.schermerhorn@hp.com \
--cc=akpm@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.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 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.