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

Nick Piggin
2007-06-13T06:44:26Z

Matt Mackall wrote:
> 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.

It's tricky as we still have the page list.

It wouldn't be difficult to add a bit-spinlock in the page flags and use
that for the intra-page list traversal, dropping the main lock after
taking the bit lock.

But even if the page list was lockless, I'd worry about locking required
to modify the list, and also, in the current scheme, multiple CPUs all
contending the same bit lock.

So I think from every angle it makes sense to break the page list into
multiple lists first. Per-cpu would be easiest.

After that, we could do lockless page list traversals (and the
finegrained page locking would make a lot of sense) -- easy way would
just be to RCU-free the struct page, cool way would be to instead use
speculative page references from the lockless pagecache :P

--
SUSE Labs, Novell Inc.