On Fri, 28 May 2010, Nick Piggin wrote: > > I am just amazed at the tosses and turns by you. Didnt you write SLQB on > > the basis of SLUB? And then it was abandoned? If you really believe ths > > Sure I hoped it would be able to conclusively beat SLAB, and I'd > thought it might be a good idea. I stopped pushing it because I > 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 plus unresolved issues with crashes on boot. I did not see you work on SLAB improvements. Seemed that other things had higher priority. The work on slab allocators in general is not well funded, not high priority and is a side issue. The time that I can spend on this is also limited. > > and want to get this done then please invest some time in SLAB to get it > > cleaned up. I have some doubt that you are aware of the difficulties that > > you will encounter. > > I am working on it. We'll see. I think we agreee on one thing regardless of SLAB or SLUB as a base: It would be good to put the best approaches together to form a superior slab allocator. I just think its much easier to do give a mature and clean code base in SLUB. If we both work on this then this may coalesce at some point. The main gripes with SLAB - Code base difficult to maintain. Has grown over almost 2 decades. - Alien caches need to be kept under control. Various hacky ways are implemented to bypass that problem. - Locking issues because of long hold times of per node lock. SLUB has locking on per page level. This is important for high number of threads per node. Westmere has already 12. EX 24 and it way grow from there. - Debugging features and recovery mechanisms. - Off or on page slab metadata causes space wastage, complex allocation and locking and alignment issues. SLED replaces that metadata structure with a bitfield in the page struct. This may also save access to additional cacheline and maybe allow freeing of objects to a slab page without taking locks. - Variable and function naming is confusing. - OS noise caused by periodic cache cleaning (which requires scans over all caches of all slabs on every processor). -- 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>