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

Matt Mackall
2007-06-13T05:42:12Z

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.