Messages in this thread | | | Date | Fri, 27 Nov 2009 11:22:36 -0600 (CST) | From | Christoph Lameter <> | Subject | Re: lockdep complaints in slab allocator |
| |
On Wed, 25 Nov 2009, Pekka Enberg wrote:
> SLUB is good for NUMA, SLAB is pretty much a disaster with it's alien > tentacles^Hcaches. AFAIK, SLQB hasn't received much NUMA attention so it's not > obvious whether or not it will be able to perform as well as SLUB or not. > > The biggest problem with SLUB is that most of the people (excluding Christoph > and myself) seem to think the design is unfixable for their favorite workload > so they prefer to either stay with SLAB or work on SLQB.
The current design of each has its own strength and its weaknesses. A queued design is not good for HPC and financial apps since it requires periodic queue cleaning (therefore disturbing a latency critical application path). Queue processing can go out of hand if there are many different types of memory (SLAB in NUMA configurations). So a queueless allocator design is good for some configurations. It is also beneficial if the allocator must be frugal with memory allocations.
There is not much difference for most workloads in terms of memory consumption between SLOB and SLUB.
> I really couldn't care less which allocator we end up with as long as it's not > SLAB. I do think putting more performance tuning effort into SLUB would give > best results because the allocator is pretty rock solid at this point. People > seem underestimate the total effort needed to make a slab allocator good > enough for the general public (which is why I think SLQB still has a long way > to go).
There are still patches queued here for SLUB that depend on other per cpu work to be merged in .33. These do not address the caching issues that people focus on for networking and enterprise apps but they decrease the minimum latency important for HPC and financial apps. The SLUB fastpath is the lowest latency allocation path that exists.
| |