From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 19 Sep 2006 14:12:03 -0700 (PDT) From: David Rientjes Subject: Re: [PATCH] GFP_THISNODE for the slab allocator In-Reply-To: Message-ID: References: <20060914220011.2be9100a.akpm@osdl.org> <20060914234926.9b58fd77.pj@sgi.com> <20060915002325.bffe27d1.akpm@osdl.org> <20060916044847.99802d21.pj@sgi.com> <20060916083825.ba88eee8.akpm@osdl.org> <20060916145117.9b44786d.pj@sgi.com> <20060916161031.4b7c2470.akpm@osdl.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Andrew Morton , Paul Jackson , linux-mm@kvack.org, rientjes@google.com List-ID: On Tue, 19 Sep 2006, Christoph Lameter wrote: > 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. > I had something similiar working when I abstracted some of the x86_64 numa=fake capabilities to work on real NUMA machines. > 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. > If the memory from existing nodes are used to create the new node, then any tasks assigned to that parent node through cpusets will be degraded. Not a problem since the user would be aware of this affect on node creation, but you'd need callback_mutex and task_lock for each task within the parent node and possibly rcu_read_lock for the mems_generation. David -- 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