On Wed, 2 Sep 2015, Mike Snitzer wrote: > You're also coming at this from a position that shared slabs are > automatically good because they have been around for years. > > For those years I've not had a need to debug a leak in code I maintain; > so I didn't notice slabs were merged. I also haven't observed slab > corruption being the cause of crashes in DM, block or SCSI. Hmmm... Thats unusual. I have seen numerous leaks and corruptions that were debugged using the additional debug code in the slab allocators. Merging and debugging can be switched on at runtime if necessary and then you will have a clear separation to be able to track down the offending code as well as detailed problem reports that help to figure out what was wrong. It is then typically even possible to fix these bugs without getting the subsystem specialists involved. > > Because clearly, that lack of statistics and the possible > > cross-subsystem corruption hasn't actually been a pressing concern in > > reality. > > Agreed. To the effect now that even SLAB has adopted cache merging. > But I'd still like some pointers/help on what makes slab merging so > beneficial. I'm sure Christoph and others have justification. But if > not then yes the default to slab merging probably should be revisited. Well, we have discussed the pros and cons for merging a couple of times but the general consensus was that it is beneficial. Performance on modern cpu is very sensitive to cache footprint and reducing the overhead of meta data for object allocation is a worthwhile goal. Also objects are more likely to be kept cache hot if they can be used by multiple subsystems. Slab merging also helps with reducing fragmentation since the free objects on one page can be used for other purposes. Check out the linux-mm archives for these dissussions. This has been such an advantage that the feature was ported to SLAB (to much more signficant effect than SLUB since SLAB is a pig with metadata per node, per cpu and per kmem_cache). And yes sorry the consequence is now that you do no longer have a choice. Both slab allocators default to merging. SLAB had some difficulty staying competitive in performance without that. Joonsoo Kim made SLAB more competitive last year and one of the optimizations was to also support merging. -- 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>