From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Van Hensbergen Subject: Re: [RFC][patch 4/7] v9fs: VFS superblock operations (2.0-rc6) Date: Wed, 25 May 2005 06:55:34 -0500 Message-ID: References: <200505232225.j4NMPte1029529@ms-smtp-02-eri0.texas.rr.com> <84144f0205052400113c6f40fc@mail.gmail.com> <1116996843.9580.8.camel@localhost> Reply-To: Eric Van Hensbergen Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Pekka Enberg , linux-kernel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org Return-path: Received: from wproxy.gmail.com ([64.233.184.192]:35089 "EHLO wproxy.gmail.com") by vger.kernel.org with ESMTP id S262157AbVEYLzg convert rfc822-to-8bit (ORCPT ); Wed, 25 May 2005 07:55:36 -0400 Received: by wproxy.gmail.com with SMTP id 68so178121wri for ; Wed, 25 May 2005 04:55:36 -0700 (PDT) To: Pekka Enberg In-Reply-To: <1116996843.9580.8.camel@localhost> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 5/24/05, Pekka Enberg wrote: > > Most subsystems also implement this (a custom allocator for tracking > memory leaks) so, yes, I think it's generally useful. However, adding > yet another custom allocator is not the way to go. Perhaps some of the > fs developers could cue in here to talk about how they track memory > leaks? Pretty please? > > In the meantime, please drop the custom allocator from your code. > Well, I'm not using slabs as a custom allocator just to track leaks. I'm using them for two specific structures which end up getting allocated and freed quite often (which is what I thought slab allocators were for). The two structures I'm slab allocating are the directory structure (which has a fixed size), and the packet structure (which has a fixed size per session, and may grow or shrink based on protocol negotiation/command-line options). I use the find_slab routine to see if there is a slab (that I created) that already matches the protocol negotiated size so I don't create a slab-per-session unnecessarily. Is this not the right way to use slabs? Should I just be using kmalloc/kcalloc? (Is that what you mean by drop the custom allocator?) Sorry if I'm being dense, just want to make sure I understand what you are saying. -eric