Re: [PATCH] GFP_THISNODE for the slab allocator

[Christoph Lameter <clameter@sgi.com>]

I guess this is the expected result. the __cpuset_zone_allowed bottleneck 
is gone.

What is workable would be to dynamically create new nodes.

The system would consist of node 0 .... MAX_PHYSNODES -1  which would 
be physical nodes.

Additional nodes beyond X MAX_PHYSNODES - 1 ... MAX_NUMNODES -1 would be 
contrainers.

A container could be created through a node hotplug API. When a node is 
created one specifies how much memory from which nodes should be assigned 
to that container / node.

Then the system will take elements off the freelists of the source nodes 
and use these as building blocks for the new nodes. All the page 
flags must be updated with the new container node number or the 
section_to_node table must be updated.

Then we should have a fully functioning node with proper statistics for 
operations. Swap / zone reclaim should work as usual on NUMA systems. The 
slab will generate its node specific structures for the new node. One 
can then cage applications using cpusets in that node.

If the container node is brought down then all pages in the node must be 
freed and will coalesce back into large higher order pages that were taken 
off the source nodes freelists. The page->flags need to be updated to 
point to the source node and then the higher order pages can be freed
back to the origin node.

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