On Wed, 2021-01-13 at 17:59 +0100, Vlastimil Babka wrote: > On 1/13/21 5:09 PM, Johannes Berg wrote: > > From: Johannes Berg <johannes.berg@xxxxxxxxx> > > > > If kmemleak is enabled, it uses a kmem cache for its own objects. > > These objects are used to hold information kmemleak uses, including > > a stack trace. If slub_debug is also turned on, each of them has > > *another* stack trace, so the overhead adds up, and on my tests (on > > ARCH=um, admittedly) 2/3rds of the allocations end up being doing > > the stack tracing. > > > > Turn off SLAB_STORE_USER if SLAB_NOLEAKTRACE was given, to avoid > > storing the essentially same data twice. > > > > Signed-off-by: Johannes Berg <johannes.berg@xxxxxxxxx> > > How about stripping away SLAB_STORE_USER only if it's added from the global > slub_debug variable? In case somebody lists one of the kmemleak caches > explicitly in "slub_debug=..." instead of just booting with "slub_debug", we > should honor that. Good point, that makes a lot of sense. TBH, I mostly sent this to see if anyone would think it acceptable. I've now disabled slub debugging completely for the kmemleak caches by command line, and as expected that improves things further. I'm _hoping_ of course that kmemleak itself doesn't contain egregious bugs, but seems like a fair bet for now :) So what do you/people think? Should we disable this? Disable all? Subject to the above constraint, either way. Thanks, johannes
