Re: [PATCH 0/5] Huge Pages Nodes Allowed

[David Rientjes <rientjes@google.com>]

On Wed, 17 Jun 2009, Lee Schermerhorn wrote:

> > > Specifically, there is no easy
> > > way to reduce the persistent huge page count for a specific node.
> > > I think the degree of control provided by these patches is the
> > > minimal necessary and sufficient for managing the persistent the
> > > huge page pool.  However, with a bit more reorganization,  we
> > > could implement per node controls if others would find that
> > > useful.
> > > 

Thanks for looking at this, it's going to be very useful.

>From a cpusets perspective, control over the hugepage allocations on 
various nodes is essential when the number of nodes on the system is not 
trivially small.  While cpusets are generally used to assign applications 
to a set of nodes to which they have affinity, they are also hierarchial 
so that within a cpuset, nodes can be further divided as a means of 
resource management.  With your extensions, this could potentially include 
hugepage management in addition to strict memory isolation.

Manipulating hugepages via a nodemask seems less ideal than, as you 
mentioned, per-node hugepage controls, probably via 
/sys/kernel/system/node/node*/nr_hugepages.  This type of interface 
provides all the functionality that this patchset does, including hugepage 
allocation and freeing, but with more power to explicitly allocate and 
free on targeted nodes.  /proc/sys/vm/nr_hugepages would remain to 
round-robin the allocation (and freeing, with your patch 1/5 which I 
ack'd).

Such an interface would also automatically deal with all memory 
hotplug/remove issues without storing or keeping a nodemask updated.

--
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>