All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>, Eric Whitney <eric.whitney@hp.com>
Subject: Re: [PATCH] Use MPOL_PREFERRED for system default policy
Date: Thu, 16 Aug 2007 10:23:41 -0400	[thread overview]
Message-ID: <1187274221.5900.27.camel@localhost> (raw)
In-Reply-To: <1187122945.6281.92.camel@localhost>

On Tue, 2007-08-14 at 16:22 -0400, Lee Schermerhorn wrote:
> On Tue, 2007-08-14 at 16:09 -0400, Lee Schermerhorn wrote:
> > On Tue, 2007-08-14 at 12:51 -0700, Christoph Lameter wrote:
> > > On Tue, 14 Aug 2007, Lee Schermerhorn wrote:
> > > 
> > > > Now, system default policy, except during boot, is "local 
> > > > allocation".  By using the MPOL_PREFERRED mode with a negative
> > > > value of preferred node for system default policy, MPOL_DEFAULT
> > > > will never occur in the 'policy' member of a struct mempolicy.
> > > > Thus, we can remove all checks for MPOL_DEFAULT when converting
> > > > policy to a node id/zonelist in the allocation paths.
> > > 
> > > Isnt it possible to set a task policy or VMA policy to MPOL_DEFAULT 
> > > through the API? For the VMA policy this would mean fall back to task 
> > > policy. Is that still possible?
> > 
> > No.  mpol_new() returns NULL if policy==MPOL_DEFAULT, so you end up just
> > deleting any existing task policy and replacing it with a NULL pointer.
> > This is pretty cool, I think.  I have checked back, but Andi may have
>                                    ^^^^ haven't!
> > done this from day 1.
> > 

Christoph, Andi:

Given that the mem policy does the right thing with this patch, can we
merge it?  I think it cleans up the mem policy concepts to have
MPOL_DEFAULT mean "use default policy for this context/scope" rather
than have an additional allocation behavior of its own.

I'll update the man pages as well, once you've had a chance to review
the current patches that Michael is holding.

Lee

--
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>

  reply	other threads:[~2007-08-16 14:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-14 19:44 [PATCH] Use MPOL_PREFERRED for system default policy Lee Schermerhorn
2007-08-14 19:51 ` Christoph Lameter
2007-08-14 20:09   ` Lee Schermerhorn
2007-08-14 20:22     ` Lee Schermerhorn
2007-08-16 14:23       ` Lee Schermerhorn [this message]
2007-08-16 18:34         ` Christoph Lameter
2007-08-16 19:06           ` Lee Schermerhorn
2007-08-16 20:49 ` Christoph Lameter
2007-08-16 21:05   ` Lee Schermerhorn
2007-08-16 21:10     ` Christoph Lameter
2007-08-21 16:00       ` Lee Schermerhorn

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=1187274221.5900.27.camel@localhost \
    --to=lee.schermerhorn@hp.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=eric.whitney@hp.com \
    --cc=linux-mm@kvack.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.