All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: clameter@sgi.com, linux-mm@kvack.org, ak@suse.de
Subject: Re: [PATCH 2.6.17-rc1-mm1 2/6] Migrate-on-fault - check for misplaced page
Date: Wed, 12 Apr 2006 13:55:12 -0700	[thread overview]
Message-ID: <20060412135512.913754f4.pj@sgi.com> (raw)
In-Reply-To: <1144867785.5229.9.camel@localhost.localdomain>

> Thanks, Paul.  But, I wonder, do I even need to do this check at all?

Quite possibly you don't need that check.  I'm pretending to be on
vacation this week and avoiding thinking too hard ;).

Hmmm ... looking around for a bit ... Notice the other code that picks
off the mempolicy.zonelist when it needs to place a page under
MPOL_BIND:


/* Return a zonelist representing a mempolicy */
static struct zonelist *zonelist_policy(gfp_t gfp, struct mempolicy *policy)
{
        int nd;

        switch (policy->policy) {
        case MPOL_PREFERRED:
                ...
                break;
        case MPOL_BIND:
                /* Lower zones don't get a policy applied */
                /* Careful: current->mems_allowed might have moved */
                if (gfp_zone(gfp) >= policy_zone)
                        if (cpuset_zonelist_valid_mems_allowed(policy->v.zonelist))
                                return policy->v.zonelist;


My recollection is that it goes like this.  If someone sets a mempolicy
MPOL_BIND on some nodes, and then someone moves that task to a cpuset
that doesn't include any of the BIND nodes, then that MPOL_BIND
mempolicy is basically ignored, until such time as if/when the task
fixes it to refer to some nodes currently allowed by its cpuset.

So my 'cpuset_zone_allowed()' suggestion was wrong.

Looks like you need a 'cpuset_zonelist_valid_mems_allowed()' check, and
if that fails, behave as if they had a default mempolicy, ignoring the
MPOL_BIND setting.

Note that I still haven't given any thought to the larger issues that
others have considered for this patch ... back to vacation.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

--
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:[~2006-04-12 20:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-07 20:18 [PATCH 2.6.17-rc1-mm1 0/6] Migrate-on-fault - Overview Lee Schermerhorn
2006-04-07 20:22 ` [PATCH 2.6.17-rc1-mm1 1/6] Migrate-on-fault - separate unmap from radix tree replace Lee Schermerhorn
2006-04-11 18:08   ` Christoph Lameter
2006-04-11 18:47     ` Lee Schermerhorn
2006-04-07 20:23 ` [PATCH 2.6.17-rc1-mm1 2/6] Migrate-on-fault - check for misplaced page Lee Schermerhorn
2006-04-11 18:21   ` Christoph Lameter
2006-04-11 19:28     ` Lee Schermerhorn
2006-04-11 19:33       ` Christoph Lameter
2006-04-12 16:43     ` Paul Jackson
2006-04-12 18:49       ` Lee Schermerhorn
2006-04-12 20:55         ` Paul Jackson [this message]
2006-04-07 20:23 ` [PATCH 2.6.17-rc1-mm1 3/6] Migrate-on-fault - migrate " Lee Schermerhorn
2006-04-11 18:32   ` Christoph Lameter
2006-04-11 19:51     ` Lee Schermerhorn
2006-04-07 20:24 ` [PATCH 2.6.17-rc1-mm1 4/6] Migrate-on-fault - handle misplaced anon pages Lee Schermerhorn
2006-04-07 20:26 ` [PATCH 2.6.17-rc1-mm1 5/6] Migrate-on-fault - add MPOL_MF_LAZY Lee Schermerhorn
2006-04-07 20:27 ` [PATCH 2.6.17-rc1-mm1 6/6] Migrate-on-fault - add MPOL_NOOP Lee Schermerhorn
2006-04-09  7:01 ` [PATCH 2.6.17-rc1-mm1 0/6] Migrate-on-fault - Overview Andi Kleen
2006-04-11 18:46 ` Christoph Lameter
2006-04-11 18:52   ` Andi Kleen
2006-04-11 19:03     ` Jack Steiner
2006-04-11 20:40       ` Lee Schermerhorn
2006-04-11 22:12         ` Jack Steiner
2006-04-11 20:40     ` Lee Schermerhorn
2006-04-11 20:40   ` 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=20060412135512.913754f4.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=ak@suse.de \
    --cc=clameter@sgi.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.