Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754524AbbDXNwl (ORCPT ); Fri, 24 Apr 2015 09:52:41 -0400 Received: from resqmta-ch2-11v.sys.comcast.net ([69.252.207.43]:58454 "EHLO resqmta-ch2-11v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754405AbbDXNwj (ORCPT ); Fri, 24 Apr 2015 09:52:39 -0400 Date: Fri, 24 Apr 2015 08:52:37 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Andrew Morton cc: Gavin Guo , penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux@rasmusvillemoes.dk Subject: Re: [PATCH v3] mm/slab_common: Support the slub_debug boot option on specific object size In-Reply-To: <20150423135106.1411031c362de2a5ef75fd50@linux-foundation.org> Message-ID: References: <1429795560-29131-1-git-send-email-gavin.guo@canonical.com> <20150423135106.1411031c362de2a5ef75fd50@linux-foundation.org> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2091 Lines: 66 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/