Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754860AbXFVHs1 (ORCPT ); Fri, 22 Jun 2007 03:48:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751153AbXFVHsT (ORCPT ); Fri, 22 Jun 2007 03:48:19 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]:65305 "EHLO mtagate4.de.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750917AbXFVHsT (ORCPT ); Fri, 22 Jun 2007 03:48:19 -0400 Message-ID: <467B7EB6.4050207@fr.ibm.com> Date: Fri, 22 Jun 2007 09:48:06 +0200 From: Cedric Le Goater User-Agent: Thunderbird 2.0.0.4 (X11/20070615) MIME-Version: 1.0 To: Christoph Lameter CC: Andrew Morton , Linux Kernel Mailing List , Herbert Poetzl , Pavel Emelianov Subject: Re: [PATCH -mm] add a kmem_cache for nsproxy objects References: <4676F0B9.3080408@fr.ibm.com> <20070619113501.a88bba50.akpm@linux-foundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1531 Lines: 47 Christoph Lameter wrote: > On Tue, 19 Jun 2007, Andrew Morton wrote: > >> On Mon, 18 Jun 2007 22:53:13 +0200 >> Cedric Le Goater wrote: >> >>> +static int __init nsproxy_cache_init(void) >>> +{ >>> + nsproxy_cachep = kmem_cache_create("nsproxy", sizeof(struct nsproxy), >>> + 0, SLAB_PANIC, NULL, NULL); >>> + return 0; >>> +} >>> + >> Christoph added this cheesy KMEM_CACHE macro. But I don't immediately recall >> the rationale so I'm a bit reluctant to ask people to use-the-cheesy-macro. >> >> Perhaps he can remind us why it is there? > > Because it simplifies the handling of slabs. > > The above will could become: > > nsproxy_cachep = KMEM_CACHE(nsproxy, SLAB_PANIC); > > meaning create a cache for the nsproxy struct, the nsproxy name and the > nsproxy size. See include/linux/slab.h. yes, I should probably use that for the nsproxy struct. my 2cts : the macro sets the align parameter to "__alignof__(struct)" by default. is that something we want to do all the time ? if so, why not change kmem_cache_create() directly ? Most of the complexity is in flags. I did a grep and picked what i thought was the most aggressive. The macro would probably be more useful if we could identify by it's name in which context it can be used. C. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/