From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 12 Sep 2007 15:10:16 -0700 (PDT) From: Christoph Lameter Subject: Re: [PATCH/RFC 3/5] Mem Policy: MPOL_PREFERRED fixups for "local allocation" In-Reply-To: <1189535671.5036.71.camel@localhost> Message-ID: References: <20070830185053.22619.96398.sendpatchset@localhost> <20070830185114.22619.61260.sendpatchset@localhost> <1189537099.32731.92.camel@localhost> <1189535671.5036.71.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Lee Schermerhorn Cc: Mel Gorman , linux-mm@kvack.org, akpm@linux-foundation.org, ak@suse.de, mtk-manpages@gmx.net, solo@google.com, eric.whitney@hp.com List-ID: On Tue, 11 Sep 2007, Lee Schermerhorn wrote: > > > case MPOL_PREFERRED: > > > - /* or use current node instead of memory_map? */ > > > + /* > > > + * for "local policy", return allowed memories > > > + */ > > > if (p->v.preferred_node < 0) > > > - *nodes = node_states[N_HIGH_MEMORY]; > > > + *nodes = cpuset_current_mems_allowed; > > > > Is this change intentional? It looks like something that belongs as part > > of the the memoryless patch set. > > > > Absolutely intentional. The use of 'node_states[N_HIGH_MEMORY]' was > added by the memoryless nodes patches. Formerly, this was > 'node_online_map'. However, even this results in misleading info for > tasks running in a cpuset. Sort of. This just means that the policy does not restrict the valid nodes. The cpuset does. I think this is okay but we may be confusing users as to which mechanism performs the restriction. > It's a fine, point, but I think this is "more correct" that the existing > code. I'm hoping that this change, with a corresponding man page update > will head off some head scratching and support calls down the road. How does this sync with the nodemasks used by other policies? So far we are using a sort of cpuset agnostic nodeset and limit it when it is applied. I think the integration between cpuset and memory policies could use some work and this is certainly something valid to do. Is there any way to describe that and have output that clarifies that distinction and helps the user figure out what is going on? -- 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: email@kvack.org