On Thu, 25 Aug 2016, Michal Hocko wrote: > I can completely see how having multiple allocators (schedulers etc...) > Because as of now, most users are using whatever is the default (SLUB > for some and never documented reason) or what their distributions come > up with. This means that we have quite a lot of code which only few > people understand deeply. Some features which are added on top need much > more testing to cover both allocators or we are risking subtle > regressions. I think the default is clear and advisable to use. The debugging features in SLAB f.e. are problematic and I have had to ask at times to retry with SLUB in order to find a subtle issue. I think the main activity nowadays is to make SLAB competitive by adopting methods from SLUB. Maybe that will work. But then concepts from SLAB can also be used in SLUB and enhance speed there. > Flexibility is always good but there comes a maintenance burden. Both > should be weighed properly. Well I thought we had that under control. SLAB is a legacy issue in many ways and people are used to the problems with debuggability if they still use that. There is always the simple way to just switch to SLUB temporarily in order to find issues. > Sure, but even after attempts to make some code common we are still at > $ wc -l mm/slab.c mm/slub.c > 4479 mm/slab.c > 5727 mm/slub.c > 10206 total > > quite a lot, don't you think? Well the code is always growing since features are being added like cgroups support and the batch allocation/freeing that is used to improve the network performance. I think this is actually quite reasonable compared with other parts of our kernel. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>