Re: [PATCH] mm/slab_common: Support the slub_debug boot option on specific object size

On Tue, 21 Apr 2015, Gavin Guo wrote: > Thanks for your reply. I put the kmalloc_names in the __initdata > section. And it will be cleaned. Do you think the kmalloc_names should > be put in the global data section to avoid the dynamic creation of the > kmalloc hostname again? Yes. -- To unsubscr

Re: [PATCH] mm/slab_common: Support the slub_debug boot option on specific object size

Hi Christoph, On Mon, Apr 20, 2015 at 11:40 PM, Christoph Lameter wrote: > On Sat, 18 Apr 2015, Gavin Guo wrote: > >> The slub_debug=PU,kmalloc-xx cannot work because in the >> create_kmalloc_caches() the s->name is created after the >> create_kmalloc_cache() is called. The name is NULL in the >>

Re: [PATCH] mm/slab_common: Support the slub_debug boot option on specific object size

On Sat, 18 Apr 2015, Gavin Guo wrote: > The slub_debug=PU,kmalloc-xx cannot work because in the > create_kmalloc_caches() the s->name is created after the > create_kmalloc_cache() is called. The name is NULL in the > create_kmalloc_cache() so the kmem_cache_flags() would not set the > slub_debug f

[PATCH] mm/slab_common: Support the slub_debug boot option on specific object size

The slub_debug=PU,kmalloc-xx cannot work because in the create_kmalloc_caches() the s->name is created after the create_kmalloc_cache() is called. The name is NULL in the create_kmalloc_cache() so the kmem_cache_flags() would not set the slub_debug flags to the s->flags. The fix here set up a tempo