On Wed, Jan 13, 2021 at 09:51:14PM +0100, 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> I think that's the simplest. Acked-by: Catalin Marinas <catalin.marinas@xxxxxxx> > Perhaps instead it should go the other way around, and kmemleak > could even use/access the stack trace that's already in there ... > But I don't really care too much, I can just turn off slub debug > for the kmemleak caches via the command line anyway :-) This stack trace doesn't seem to be accessible in a unified way across the sl*b allocators. Given that kmemleak already needs to track this information for other objects (vmalloc, certain page allocations), it's probably more hassle to handle it differently for slab objects (I don't say it's impossible, just not sure it's worth). -- Catalin
