From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH] slab+slob: dup name string Date: Wed, 23 May 2012 16:08:08 +0400 Message-ID: <4FBCD328.6060406@parallels.com> References: <1337613539-29108-1-git-send-email-glommer@parallels.com> <4FBBAE95.6080608@parallels.com> <1337773595.3013.15.camel@dabdike.int.hansenpartnership.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1337773595.3013.15.camel@dabdike.int.hansenpartnership.com> Sender: owner-linux-mm@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: James Bottomley Cc: David Rientjes , Christoph Lameter , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Pekka Enberg On 05/23/2012 03:46 PM, James Bottomley wrote: >> We can't predict how slab will be extended in the future and this affects >> > anything created before g_cpucache_cpu<= EARLY. This would introduce the >> > first problem with destroying such caches and is unnecessary if a >> > workaround exists. > These problems seem to indicate that the slab behaviour: expecting the > string to exist for the lifetime of the cache so there's no need to copy > it might be better. > > This must be the behaviour all users of kmem_cache_create() expect > anyway, since all enterprise distributions use slab and they're not > getting bugs reported in this area. > > So, why not simply patch slab to rely on the string lifetime being the > cache lifetime (or beyond) and therefore not having it take a copy? > You mean patch slub? slub is the one that takes a copy currently. -- 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