From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Enberg Subject: Re: [RFC][patch 4/7] v9fs: VFS superblock operations (2.0-rc6) Date: Wed, 25 May 2005 07:54:03 +0300 Message-ID: <1116996843.9580.8.camel@localhost> References: <200505232225.j4NMPte1029529@ms-smtp-02-eri0.texas.rr.com> <84144f0205052400113c6f40fc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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 courier.cs.helsinki.fi ([128.214.9.1]:30870 "EHLO mail.cs.helsinki.fi") by vger.kernel.org with ESMTP id S262266AbVEYE4a (ORCPT ); Wed, 25 May 2005 00:56:30 -0400 To: Eric Van Hensbergen In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi, On Tue, 2005-05-24 at 14:08 -0500, Eric Van Hensbergen wrote: > 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? 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. Pekka