On Tue, May 25, 2010 at 08:02:32PM +0300, Pekka Enberg wrote: > Hi Nick, > > On Tue, May 25, 2010 at 6:43 PM, Nick Piggin <npiggin@xxxxxxx> wrote: > > As far as I can see, there was never a good reason to replace SLAB > > rather than clean up its code and make incremental improvements. > > I'm not totally convinced but I guess we're about to find that out. > How do you propose we benchmark SLAB while we clean it up Well the first pass will be code cleanups, bootstrap simplifications. Then looking at what debugging features were implemented in SLUB but not SLAB and what will be useful to bring over from there. At this point the aim would be for actual allocation behaviour with non-debug settings to be unchanged. Hopefully this removes everyone's (apparently) largest gripe that code is crufty. Next would be to add some options to tweak queue sizes and disable cache reaping at runtime, for the benfit of the low jitter crowd, see if any further hotplug fixes are required. Then would be to propose incremental improvements to actual algorithm. For example, replacing the alien cache crossbar with a lighter weight or more scalable structure. > and change > things to make sure we don't make the same mistakes as we did with > SLUB (i.e. miss an important workload like TPC-C)? Obviously it is impossible to make forward progress and also catch all regressions before release. This fact means that we have to be able to cope with them as well as possible. We get two benefits from starting with SLAB. Firstly, we get a larger testing base. Secondly, we get a simple (ie. git revert) formula of how to get from good behaviour to bad behaviour. I don't anticipate a huge number of functional changes to SLAB here though. It's surprisingly hard to do better than it. alien caches are one area, maybe configurable higher order allocation support, jitter reduction. If we do get a big proposed change in the pipeline, then we have to eat it somehow, but AFAIKS we've still got a better foundation than starting with a completely new allocator and feeling around in the dark trying to move it past SLAB in terms of performance. -- 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>