On Fri, 28 May 2010, Nick Piggin wrote: > > > realized that incremental improvements to SLAB would likely be a > > > far better idea. > > > > It looked to me as if there was a major conceptual issue with the linked > > lists used for objects that impacted performance > > With SLQB's linked list? No. Single threaded cache hot performance was > the same (+/- a couple of cycles IIRC) as SLUB on your microbenchmark. > On Intel's OLTP workload it was as good as SLAB. > > The linked lists were similar to SLOB/SLUB IIRC. Yes that is the problem. So it did not address the cache cold regressions in SLUB. SLQB mostly addressed the slow path frequency on free. The design of SLAB is superior for cache cold objects since SLAB does not touch the objects on alloc and free (if one requires similar cache cold performance from other slab allocators) thats why I cleaned up the per cpu queueing concept in SLAB (easy now with the percpu allocator and operations) and came up with SLEB. At the same time this also addresses the slowpath issues on free. I am not entirely sure how to deal with the NUMAness but I want to focus more on machines with low node counts. The problem with SLAB was that so far the "incremental improvements" have lead to more deteriorations in the maintainability of the code. There are multiple people who have tried going this route that you propose. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>