From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH v2] slab+slob: dup name string Date: Wed, 23 May 2012 13:25:23 +0400 Message-ID: <4FBCAD03.5010106@parallels.com> References: <1337680298-11929-1-git-send-email-glommer@parallels.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: David Rientjes Cc: Christoph Lameter , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Pekka Enberg On 05/23/2012 07:55 AM, David Rientjes wrote: > I hate consistency patches like this because it could potentially fail a > kmem_cache_create() from a sufficiently long cache name when it wouldn't > have before, but I'm not really concerned since kmem_cache_create() will > naturally be followed by kmem_cache_alloc() which is more likely to cause > the oom anyway. But it's just another waste of memory for consistency > sake. > > This is much easier to do, just statically allocate the const char *'s > needed for the boot caches and then set their ->name's manually in > kmem_cache_init() and then avoid the kfree() in kmem_cache_destroy() if > the name is between&boot_cache_name[0] and&boot_cache_name[n]. That can be done. I'll also revisit my memcg patches to see if I can rework it so it doesn't care about this particular behavior. We're having a surprisingly difficult time reaching consensus on this, so maybe it would be better left untouched (if there is a way that makes sense to)