Re: [PATCH v2] mm/slub: disable user tracing for kmemleak caches by default

2021-01-15 Thread David Rientjes
On Wed, 13 Jan 2021, Johannes Berg wrote: > From: Johannes Berg > > 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,

Re: [PATCH v2] mm/slub: disable user tracing for kmemleak caches by default

2021-01-14 Thread Catalin Marinas
On Wed, Jan 13, 2021 at 09:51:14PM +0100, Johannes Berg wrote: > From: Johannes Berg > > 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 >

Re: [PATCH v2] mm/slub: disable user tracing for kmemleak caches by default

2021-01-14 Thread Vlastimil Babka
On 1/13/21 9:51 PM, Johannes Berg wrote: > From: Johannes Berg > > 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,

[PATCH v2] mm/slub: disable user tracing for kmemleak caches by default

2021-01-13 Thread Johannes Berg
From: Johannes Berg 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,