From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Andi Kleen <ak@suse.de>
Cc: David Rientjes <rientjes@google.com>, Paul Jackson <pj@sgi.com>,
akpm@linux-foundation.org, clameter@sgi.com,
linux-kernel@vger.kernel.org
Subject: Re: [patch -mm 2/2] mempolicy: use default_policy mode instead of MPOL_DEFAULT
Date: Mon, 10 Mar 2008 09:48:01 -0400 [thread overview]
Message-ID: <1205156881.5579.5.camel@localhost> (raw)
In-Reply-To: <200803090019.19518.ak@suse.de>
On Sun, 2008-03-09 at 00:19 +0100, Andi Kleen wrote:
> > Using MPOL_DEFAULT purely for falling back to the task or system-wide
> > policy, however, seems confusing. The semantics seem to indicate that
> > MPOL_DEFAULT represents the system-wide default policy without any
> > preferred node or set of nodes to bind or interleave. So if a VMA has a
> > policy of MPOL_DEFAULT then, to me, it seems like that indicates the
> > absence of a specific policy, not a mandate to fallback to the task
> > policy.
>
> I designed MPOL_DEFAULT on vma originally to be a fallback to the task policy.
>
> Absence of specific policy would be MPOL_PREFERRED with -1 node.
Not sure what you mean here, Andi.
"MPOL_PREFERRED with -1 node" == "local allocation", right?
Whereas, in the task mempolicy or vma policy or shared policy, the lack
of a specific policy--i.e., a null mempolicy pointer, or no policy at
that offset in a shared policy rbtree--means fall back to surrounding
context, right? As far back as I've looked, mempolicy.c implemented
MPOL_DEFAULT, passed to set_mempolicy() or mbind(), by deleting the
target policy, resulting in "fall back".
The only place that MPOL_DEFAULT actually occurs in a struct mempolicy
is in the system default policy. I think we can simplify the code and
documentation--not have to explain the context dependent meaning of
MPOL_DEFAULT--by making it simply an API request to remove the target
policy and establish "default behavior" for that context--i.e.,
fallback.
Lee
>
> -Andi
>
>
>
next prev parent reply other threads:[~2008-03-10 13:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-08 1:24 [patch -mm 1/2] mempolicy: disallow static or relative flags for local preferred mode David Rientjes
2008-03-08 1:24 ` [patch -mm 2/2] mempolicy: use default_policy mode instead of MPOL_DEFAULT David Rientjes
2008-03-08 1:28 ` Paul Jackson
2008-03-08 1:33 ` David Rientjes
2008-03-08 1:35 ` Paul Jackson
2008-03-08 1:59 ` Christoph Lameter
2008-03-08 2:14 ` David Rientjes
2008-03-08 19:13 ` Lee Schermerhorn
2008-03-08 22:20 ` David Rientjes
2008-03-08 23:19 ` Andi Kleen
2008-03-10 13:48 ` Lee Schermerhorn [this message]
2008-03-10 19:09 ` [patch -mm 1/2] mempolicy: disallow static or relative flags for local preferred mode Andrew Morton
2008-03-10 19:20 ` what to patch Randy Dunlap
2008-03-10 19:55 ` Andrew Morton
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=1205156881.5579.5.camel@localhost \
--to=lee.schermerhorn@hp.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
--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.