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

[Christoph Lameter]

On Thu, 23 Apr 2015, Andrew Morton wrote:
> >
> > +		if (i == 2)
> > +			i = (KMALLOC_SHIFT_LOW - 1);
>
> Can we get rid of this by using something like

Nope index is a ilog2 value of the size. The table changes would not
preserve the mapping of the index to the power of two sizes.

> static struct {
> 	const char *name;
> 	unsigned long size;
> } const kmalloc_names[] __initconst = {
> //	{NULL,                      0},
> 	{"kmalloc-96",             96},
> 	{"kmalloc-192",           192},
> #if KMALLOC_MIN_SIZE <= 8
> 	{"kmalloc-8",               8},
> #endif
> #if KMALLOC_MIN_SIZE <= 16
> 	{"kmalloc-16",             16},
> #endif
> #if KMALLOC_MIN_SIZE <= 32
> 	{"kmalloc-32",             32},
> #endif
> 	{"kmalloc-64",             64},
> 	{"kmalloc-128",           128},
> 	{"kmalloc-256",           256},
> 	{"kmalloc-512",           512},
> 	{"kmalloc-1024",         1024},
> 	{"kmalloc-2048",         2048},
> 	{"kmalloc-4096",         4096},
> 	{"kmalloc-8192",         8192},
> 	...
> };
>

> Why does the initialization code do the
>
> 	if (!kmalloc_caches[i]) {
>
> test?  Can any of these really be initialized?  If so, why is it
> legitimate for create_kmalloc_caches() to go altering size_index[]
> after some caches have already been set up?

Because we know what sizes we need during bootstrap and the initial
caches that are needed to create others are first populated. If they are
already handled by the earliest bootstrap code then we should not
repopulate them later.

> Finally, why does create_kmalloc_caches() use GFP_NOWAIT?  We're in
> __init code!  Makes no sense.  Or if it *does* make sense, the reason
> should be clearly commented.

Well I was told by Pekka to use it exactly because it was init code at
some point. The slab system is not really that functional so I doubt
it makes much of a difference.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/