Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261938AbVEXTIu (ORCPT ); Tue, 24 May 2005 15:08:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261919AbVEXTIu (ORCPT ); Tue, 24 May 2005 15:08:50 -0400 Received: from wproxy.gmail.com ([64.233.184.197]:53778 "EHLO wproxy.gmail.com") by vger.kernel.org with ESMTP id S261499AbVEXTIp convert rfc822-to-8bit (ORCPT ); Tue, 24 May 2005 15:08:45 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I3wckEvv7Kg3xgN829uDXo/5kMBeiTfNt4QqKX4o7HxP+oN6pLbVAWf7dXBa1I/k02OWiZjHfdYWR0Z8WO1Z9sBDEz9yR4y3s5L3psrk5hkXsykrMArmi5b6khRn7ymGTv+Tvl1n7PQG/UGpCRkWcGHa4zPuD3WOvLYobMfT9yI= Message-ID: Date: Tue, 24 May 2005 14:08:44 -0500 From: Eric Van Hensbergen Reply-To: Eric Van Hensbergen To: Pekka Enberg Subject: Re: [RFC][patch 4/7] v9fs: VFS superblock operations (2.0-rc6) Cc: linux-kernel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org, penberg@cs.helsinki.fi In-Reply-To: <84144f0205052400113c6f40fc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline References: <200505232225.j4NMPte1029529@ms-smtp-02-eri0.texas.rr.com> <84144f0205052400113c6f40fc@mail.gmail.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1117 Lines: 30 On 5/24/05, Pekka Enberg wrote: > > > + > > +/** > > + * find_slab - look up a slab by size > > + * @size: size of slab data > > + * > > + */ > > + > > +static inline kmem_cache_t *find_slab(int size) > > Hmm? Why do you need this? If you're missing functionality from the > slab allocator, please put that in mm/slab.c, not your filesystem! > Thanks for the comments! A bit of a clarification on slab policy - I did my own find_slab() so I could keep tight control over my own slabs (and monitor for slab leaks, etc.). There seems to be similar functionality for the malloc slabs (kmem_find_general_cachep), but I'm not sure if this is really something that is generally useful. What do folks think? Is this something that would be generally useful to add to slab.c? Or is there something like this that I just overlooked? -eric - 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/