Re: [PATCH] numa: mempolicy: dynamic interleave map for system init.

[Paul Mundt <lethal@linux-sh.org>]

On Tue, Jun 12, 2007 at 10:32:34AM -0500, Matt Mackall wrote:
> On Tue, Jun 12, 2007 at 06:43:59PM +0900, Paul Mundt wrote:
> > On Fri, Jun 08, 2007 at 09:50:11AM -0500, Matt Mackall wrote:
> > > Haven't given any thought to NUMA yet though..
> > > 
> > This is what I've hacked together and tested with my small nodes. It's
> > not terribly intelligent, and it pushes off most of the logic to the page
> > allocator. Obviously it's not terribly scalable, and I haven't tested it
> > with page migration, either. Still, it works for me with my simple tmpfs
> > + mpol policy tests.
> > 
> > Tested on a UP + SPARSEMEM (static, not extreme) + NUMA (2 nodes) + SLOB
> > configuration.
> > 
> > Flame away!
> 
> For starters, it's not against the current SLOB, which no longer has
> the bigblock list.
> 
Sorry about that, seems I used the wrong tree.

> > -void *__kmalloc(size_t size, gfp_t gfp)
> > +static void *__kmalloc_alloc(size_t size, gfp_t gfp, int node)
> 
> That's a ridiculous name. So, uh.. more underbars!
> 
Agreed, though I couldn't think of a better one.

> Though really, I think you can just name it __kmalloc_node?
> 
No, kmalloc_node and __kmalloc_node are both required by CONFIG_NUMA,
otherwise that would have been the logical choice.

> > +		if (node == -1)
> > +			pages = alloc_pages(flags, get_order(c->size));
> > +		else
> > +			pages = alloc_pages_node(node, flags,
> > +						get_order(c->size));
> 
> This fragment appears a few times. Looks like it ought to get its own
> function. And that function can reduce to a trivial inline in the
> !NUMA case.
> 
Ok.

> > +void *kmem_cache_alloc_node(struct kmem_cache *c, gfp_t flags, int node)
> > +{
> > +	return __kmem_cache_alloc(c, flags, node);
> > +}
> 
> If we make the underlying functions all take a node, this stuff all
> gets simpler.
> 
Could you elaborate on that? We only require the node specifier in the
allocation path, and this simply hands it down in accordance with the
existing APIs. After allocation time the node id is encoded in the page
flags, so we can easily figure out which node a page is tied to.

I'll post the updated patch separately.

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