Re: [RFC][patch 4/7] v9fs: VFS superblock operations (2.0-rc6)

[Eric Van Hensbergen]

On 5/24/05, Pekka Enberg <penberg@xxxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/