LKML Archive on
help / color / mirror / Atom feed
From: Lee Schermerhorn <>
To: David Rientjes <>
Cc: Paul Jackson <>,,,,
Subject: Re: [patch -mm 2/2] mempolicy: use default_policy mode instead of MPOL_DEFAULT
Date: Sat, 08 Mar 2008 14:13:00 -0500	[thread overview]
Message-ID: <1205003580.4918.21.camel@localhost> (raw)
In-Reply-To: <>

On Fri, 2008-03-07 at 17:33 -0800, David Rientjes wrote:
> On Fri, 7 Mar 2008, Paul Jackson wrote:
> > > So instead of checking for comparisons against a mempolicy's mode to
> > > MPOL_DEFAULT or falling back stricly to MPOL_DEFAULT throughout the code,
> > > we should use the mode that is defined in this struct.
> > 
> > Is this just a stylistic choice?  That is, is the same machine
> > code produced either way?
> > 
> > If that's the case, could you briefly explain why you prefer
> > one style (default_policy.policy) over the other (MPOL_DEFAULT)?
> > 
> Very fast response!
> Yes, the same code is generated since default_policy.policy is statically 
> declared as MPOL_DEFAULT.
> I chose this because checks in mpol_new() to return NULL if the mode is 
> MPOL_DEFAULT is purely based on the fact that, as the default system 
> policy, policy task or VMA pointers are set to &default_policy.

Do I understand that you're saying that when mode is specified as
MPOL_DEFAULT, the current task policy [in the case of set_mempolicy()]
or the indicated vma policy [in the case of mbind()] is set to
&default_policy?  If that's not what you're saying, please disregard the
rest of this message.

If that is what you're saying:   This is not the case.  When mode is
specified as MPOL_DEFAULT,  mpol_new() returns NULL and
do_set_mempolicy() or do_mbind() [via it's helper functions] replaces
the existing task or vma policy with the NULL, freeing [releasing a
reference on] the existing policy, if any.  This results in the target
policy--task or vma--"falling back" to the surrounding policy scope.
This seems to have been the behavior as far back as I have looked.

In fact, the only place that MPOL_DEFAULT occurs in the policy [mode]
member of struct mempolicy is in the system default_policy.  [As
Christoph noted, this is not the case during system initialization.]  In
this context, it means "local allocation".  This requires us to have the
MPOL_DEFAULT case in the switches throughout mempolicy.c.

I have a patch queued up, waiting for things to settle down in
mempolicy.c, to replace the policy/mode in default_policy with
MPOL_PREFERRED with preferred_node = -1.  Then, we can remove all of the
MPOL_DEFAULT cases out of the switches in the allocation paths and
"clean up" the documentation, including man pages.  MPOL_DEFAULT becomes
simply an API mechanism to request fall back to the surrounding policy
scope which, to my mind, is what "default policy" means.

I don't have a problem with this patch in the context of the current
implementation, altho' it does seem a bit pointless to me, unless you
have something further that you're trying to to accomplish.

I'll move the aforementioned patch to the head of my queue and send it
out early this coming week for review atop whatever mempolicy patches
Andrew has added to the tree at that time.


  parent reply	other threads:[~2008-03-08 19:13 UTC|newest]

Thread overview: 12+ 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 [this message]
2008-03-08 22:20         ` David Rientjes
2008-03-08 23:19           ` Andi Kleen
2008-03-10 13:48             ` Lee Schermerhorn
2008-03-10 19:09 ` [patch -mm 1/2] mempolicy: disallow static or relative flags for local preferred mode 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1205003580.4918.21.camel@localhost \ \ \ \ \ \ \ \
    --subject='Re: [patch -mm 2/2] mempolicy: use default_policy mode instead of MPOL_DEFAULT' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).