Messages in this thread | | | Date | Fri, 27 Nov 2009 11:26:54 -0600 (CST) | From | Christoph Lameter <> | Subject | Re: lockdep complaints in slab allocator |
| |
On Tue, 24 Nov 2009, Pekka Enberg wrote:
> Yeah, something like that. I don't think we were really able to decide > anything at the KS. IIRC Christoph was in favor of having multiple > slab allocators in the tree whereas I, for example, would rather have > only one. The SLOB allocator is bit special here because it's for > embedded. However, I also talked to some embedded folks at the summit > and none of them were using SLOB because the gains weren't big enough. > So I don't know if it's being used that widely.
Are there any current numbers on SLOB memory advantage vs the other allcoators?
> I personally was hoping for SLUB or SLQB to emerge as a clear winner > so we could delete the rest but that hasn't really happened.
I think having multiple allocators makes for a heathly competition between them and stabillizes the allocator API. Frankly I would like to see more exchangable subsystems in the core. The scheduler seems to be not competitive for my current workloads running on 2.6.22 (we have not tried 2.6.32 yet) and I have a lot of concerns about the continual performance deteriorations in the page allocator and the reclaim logic due to feature bloat.
| |