Re: [PATCH] slob: poor man's NUMA, take 2.

Paul Mundt
2007-06-13T04:13:19Z

On Wed, Jun 13, 2007 at 01:42:28PM +1000, Nick Piggin wrote:
> Nick Piggin wrote:
> >Paul Mundt wrote:
>
> >>That's why I tossed in the node id matching in slob_alloc() for the
> >>partial free page lookup. At the moment the logic obviously won't scale,
> >>since we end up scanning the entire freelist looking for a page that
> >>matches the node specifier. If we don't find one, we could rescan and
> >>just grab a block from another node, but at the moment it just continues
> >>on and tries to fetch a new page for the specified node.
> >
> >
> >Oh, I didn't notice that. OK, sorry that would work.
>
> OTOH, there are lots of places that don't specify the node explicitly,
> but most of them prefer the allocation to come from the current node...
> and that case isn't handled very well is it?
>
Well, we could throw in a numa_node_id() for kmem_cache_alloc() and
__kmalloc(), that would actually simplify slob_new_page(), since we can
just use alloc_pages_node() directly in the NUMA case without special
casing the node id.

This also has the side-effect of working well on UP with asymmetric nodes
(assuming a larger node 0), since numa_node_id() will leave us with a
node 0 preference in places where the node id isn't explicitly given.