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) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx157.postini.com [74.125.245.157]) by kanga.kvack.org (Postfix) with SMTP id BDC696B0092 for ; Wed, 23 May 2012 05:27:26 -0400 (EDT) Message-ID: <4FBCAD03.5010106@parallels.com> Date: Wed, 23 May 2012 13:25:23 +0400 From: Glauber Costa MIME-Version: 1.0 Subject: Re: [PATCH v2] slab+slob: dup name string References: <1337680298-11929-1-git-send-email-glommer@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: Christoph Lameter , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.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) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758236Ab2EWJ11 (ORCPT ); Wed, 23 May 2012 05:27:27 -0400 Received: from mx2.parallels.com ([64.131.90.16]:51740 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751859Ab2EWJ10 (ORCPT ); Wed, 23 May 2012 05:27:26 -0400 Message-ID: <4FBCAD03.5010106@parallels.com> Date: Wed, 23 May 2012 13:25:23 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: David Rientjes CC: Christoph Lameter , , , , Pekka Enberg Subject: Re: [PATCH v2] slab+slob: dup name string References: <1337680298-11929-1-git-send-email-glommer@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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)