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

[Matt Mackall <mpm@selenic.com>]

On Tue, Jun 12, 2007 at 10:30:04PM -0700, Christoph Lameter wrote:
> Hmmmm. One key advantage that SLOB has over all allocators is the density 
> of the kmalloc array. I tried to add various schemes to SLUB but there is 
> still a difference of 340kb on boot. If you get it to do NUMA then may be 
> we can get a specialized allocator for the kmalloc array out of all of 
> this?
> 
> If you focus on the kmalloc array then you can avoid to deal with certain 
> other issues
> 
> - No ctor, no reclaim accounting, no rcu etc.
> - No need to manage partial slabs.
> - No slab creation, destruction etc.

That's an interesting point.

> Maybe that could done in a pretty compact way and replace the space 
> wasting kmalloc arrays in SLAB and SLUB?

We'll need to up the SMP scalability for that to make sense. Using
page flags for per-page locking and such might be a start. I've been
hoping Nick would propose something here, as those sorts of hacks seem
to be his thing.

-- 
Mathematics is the supreme nostalgia of our time.

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