Do you need a guarantee against blocking or disabling interrupts,
or do you just need very fast allocation? I could propose a very
simple front end with a typical allocation time of 2 xchg
instructions (+ one pointer dereference), a worst case same as
current slab, and no need for per-engine queues.
I'm not sure what all the issues here are, but agree with Mark that
we should put the effort into one highly optimized well-tested
allocator.
SIMP is fast because it can rely on the following premises:
1) The local per-cpu pool is only accesses from the current processor
2) Interrupts never ever try to get at a SIMP pool
Because of this, it can implement SMP safety at zero cost, no xchg's,
no spinlocks, no rwlock's, nothing at all. All localized and cache
friendly.
SLAB can never make these assumptions, and thus not have these
performance characteristics. There is only one way around it and I am
not even certain it would work or not:
1) Add different front end calls for the SLAB, clients calling this
set of interfaces are informing SLAB that they never will make
any calls to SLAB functions etc. from within an interrupt handler.
2) Change these new interfaces to use per-cpu SLAB object pools.
Adding to a generic SLAB the per-cpu magazines is a tough problem and
very difficult to get right when IRQ's allocating from the object pool
is a possibility.
SIMP should not be removed until SLAB can provide all of the
advantages SIMP has and at the same level of performance. This means:
1) No SMP locking in the common case, xchg's are verboten as well.
2) No cli()'s in any code path whatsoever.
Comments?
Later,
David "Sparc" Miller
davem@caip.rutgers.edu