increase kmemleak robustness at boot
in [Kernel]
|
Prev: [PATCH 03/10] sh: dma: check return value of create_proc_read_entry()
Next: [PATCH 04/10] x86: mce: fix error handling
From: Daniel J Blueman on 29 Jul 2010 14:10 On 29 July 2010 16:12, Pekka Enberg <penberg(a)cs.helsinki.fi> wrote: > Daniel J Blueman wrote: >>> >>> I would rather change the static early alloc buffer with something >>> like bootmem allocation (the recursiveness should be bound, kmemleak >>> tracks bootmem allocations as well). But I'm on holiday until middle >>> of August and not able to do any tests in this area. >> >> Indeed, moving to dynamic early allocation is all the more better. For >> now, I'll increase the early allocation to 15200 elements, as the >> 400-entry buffer wraps 38. > > If it's just kmemleak_init() we're talking about, slab caches are up at that > point so you can just use kmalloc(). The slab allocator isn't up at this point. With CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE set to 16K elements, an extra 3MB of __initdata memory is used, but freed afterwards, and it works great. Thanks, Daniel -- Daniel J Blueman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 29 Jul 2010 15:00 On Thu, Jul 29, 2010 at 9:03 PM, Daniel J Blueman <daniel.blueman(a)gmail.com> wrote: >> If it's just kmemleak_init() we're talking about, slab caches are up at that >> point so you can just use kmalloc(). > > The slab allocator isn't up at this point. With > CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE set to 16K elements, an extra 3MB > of __initdata memory is used, but freed afterwards, and it works > great. Right. I guess the required earlylog buffer size would be smaller if we initialized kmemleak earlier. Can we do that in mm_init() after kmem_cache_init()? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Catalin Marinas on 29 Jul 2010 16:40 On 29 July 2010 19:50, Pekka Enberg <penberg(a)cs.helsinki.fi> wrote: > On Thu, Jul 29, 2010 at 9:03 PM, Daniel J Blueman > <daniel.blueman(a)gmail.com> wrote: >>> If it's just kmemleak_init() we're talking about, slab caches are up at that >>> point so you can just use kmalloc(). >> >> The slab allocator isn't up at this point. With >> CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE set to 16K elements, an extra 3MB >> of __initdata memory is used, but freed afterwards, and it works >> great. > > Right. I guess the required earlylog buffer size would be smaller if > we initialized kmemleak earlier. Can we do that in mm_init() after > kmem_cache_init()? Kmemleak uses kmem_cache_alloc() internally so we could initialise it as soon as kmem_cache_init() was called. But it's really strange the amount of early allocations that Daniel is getting. I've been happy so far with 400, usually with standard Ubuntu-like configs and some debugging turned on. Any idea what's causing these allocations? -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 31 Jul 2010 05:50
Catalin Marinas wrote: >> Right. I guess the required earlylog buffer size would be smaller if >> we initialized kmemleak earlier. Can we do that in mm_init() after >> kmem_cache_init()? > > Kmemleak uses kmem_cache_alloc() internally so we could initialise it > as soon as kmem_cache_init() was called. But it's really strange the > amount of early allocations that Daniel is getting. I've been happy so > far with 400, usually with standard Ubuntu-like configs and some > debugging turned on. Any idea what's causing these allocations? No idea. I wonder if kmemleak can dump out the call-sites for the overflow case somehow to see what's going on? Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |