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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/24/05, Pekka Enberg <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux