[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1193434278.5032.106.camel@localhost>
Date: Fri, 26 Oct 2007 17:31:17 -0400
From: Lee Schermerhorn <Lee.Schermerhorn@...com>
To: David Rientjes <rientjes@...gle.com>
Cc: Paul Jackson <pj@....com>, clameter@....com,
akpm@...ux-foundation.org, ak@...e.de, linux-kernel@...r.kernel.org
Subject: Re: [patch 2/2] cpusets: add interleave_over_allowed option
On Fri, 2007-10-26 at 14:18 -0700, David Rientjes wrote:
> On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
>
> > You don't need to save the entire mask--just note that NODE_MASK_ALL was
> > passed--like with my internal MPOL_CONTEXT flag. This would involve
> > special casing NODE_MASK_ALL in the error checking, as currently
> > set_mempolicy() complains loudly if you pass non-allowed nodes--see
> > "contextualize_policy()". [mbind() on the other hand, appears to allow
> > any nodemask, even outside the cpuset. guess we catch this during
> > allocation.] This is pretty much the spirit of my patch w/o the API
> > change/extension [/improvement :)]
> >
>
> Not really, because perhaps your application doesn't want to interleave
> over all nodes. I suggested NODE_MASK_ALL as the way to get access to all
> the memory you are allowed, but it's certainly plausible that an
> application could request to interleave only over a subset. That's the
> entire reason set_mempolicy(MPOL_INTERLEAVE) takes a nodemask anyway right
> now instead of just using task->mems_allowed on each allocation.
So, you pass the subset, you don't set the flag to indicate you want
interleaving over all available. You must be thinking of some other use
for saving the subset mask that I'm not seeing here. Maybe restoring to
the exact nodes requested if they're taken away and then re-added to the
cpuset?
Later,
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists