Re: [PATCH 5/5] [hugetlb] Try to grow pool for MAP_SHARED mappings

[Lee Schermerhorn <Lee.Schermerhorn@hp.com>]

On Fri, 2007-07-20 at 13:35 -0700, Nish Aravamudan wrote:
> On 7/18/07, Paul Mundt <lethal@linux-sh.org> wrote:
<snip>
> > It would be quite nice to have some way to have nodes opt-in to the sort
> > of behaviour they're willing to tolerate. Some nodes are never going to
> > tolerate spreading of any sort, hugepages, and so forth. Perhaps it makes
> > more sense to have some flags in the pgdat where we can more strongly
> > type the sort of behaviour the node is willing to put up with (or capable
> > of supporting), at least in this case the nodes that explicitly can't
> > cope are factored out before we even get to cpuset constraints (plus this
> > gives us a hook for setting up the interleave nodes in both the system
> > init and default policies). Thoughts?
> 
> I guess I don't understand which nodes you're talking about now? How
> do you spread across any particular single node (how I read "Some
> nodes are never going to tolerate spreading of any sort")? Or do you
> mean that some cpusets aren't going to want to spread (interleave?).
> 
> Oh, are you trying to say that some nodes should be dropped from
> interleave masks (explicitly excluded from all possible interleave
> masks)? What kind of nodes would these be? We're doing something
> similar to deal with memoryless nodes, perhaps it could be
> generalized?

If that's what Paul means [and I think it is, based on a converstation
at OLS], I have a similar requirement.  I'd like to be able to specify,
on the command line, at least [run time reconfig not a hard requirement]
nodes to be excluded from interleave masks, including the hugetlb
allocation mask [if this is different from the regular interleaving
nodemask].  

And, I agree, I think we can add another node_states[] entry or two to
hold these nodes.  I'll try to work up a patch next week if noone beats
me to it.

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>