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

Lee Schermerhorn
2007-07-20T20:53:58Z

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