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]
