From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx141.postini.com [74.125.245.141]) by kanga.kvack.org (Postfix) with SMTP id DB5106B0083 for ; Wed, 23 May 2012 08:10:11 -0400 (EDT) Message-ID: <4FBCD328.6060406@parallels.com> Date: Wed, 23 May 2012 16:08:08 +0400 From: Glauber Costa MIME-Version: 1.0 Subject: Re: [PATCH] slab+slob: dup name string References: <1337613539-29108-1-git-send-email-glommer@parallels.com> <4FBBAE95.6080608@parallels.com> <1337773595.3013.15.camel@dabdike.int.hansenpartnership.com> In-Reply-To: <1337773595.3013.15.camel@dabdike.int.hansenpartnership.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: 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