From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH] slab+slob: dup name string Date: Thu, 24 May 2012 10:18:31 +1000 Message-ID: <20120524001831.GQ25351@dastard> References: <4FBBAE95.6080608@parallels.com> <1337773595.3013.15.camel@dabdike.int.hansenpartnership.com> <4FBCD328.6060406@parallels.com> <1337775878.3013.16.camel@dabdike.int.hansenpartnership.com> <4FBCF951.3040105@parallels.com> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <4FBCF951.3040105-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Glauber Costa Cc: Christoph Lameter , James Bottomley , David Rientjes , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Pekka Enberg On Wed, May 23, 2012 at 06:50:57PM +0400, Glauber Costa wrote: > On 05/23/2012 06:48 PM, Christoph Lameter wrote: > >On Wed, 23 May 2012, James Bottomley wrote: > > > >>>>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? > > > >Well thats they way it was for a long time. There must be some reason that > >someone started to add this copying business.... Pekka? > > > The question is less why we added, but rather why we're keeping. > > Of course reasoning about why it was added helps (so let's try to > determine that), but so far the only reasonably strong argument in > favor of keeping it was robustness. I'm pretty sure it was added because there are slab names constructed by snprintf on a stack buffer, so the name doesn't exist beyond the slab initialisation function call... Cheers, Dave. -- Dave Chinner david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org