|
|
Subscribe / Log in / New account

Detecting kernel memory leaks

Detecting kernel memory leaks

Posted Jun 22, 2006 13:11 UTC (Thu) by liljencrantz (guest, #28458)
Parent article: Detecting kernel memory leaks

One way to avoid some memory leaks is to have better ways to specify memory lifetimes.

The traditional memory allocation lifetimes are:

* 'the life of the current function' for allocations on the stack
* 'until I manually free this memory' for allocations on the heap
* 'when the number of users hits zero' for reference counting

All of these are very usable in and taken together they can be quite versatile.

There is however one other allocation model that I often find very useful; namely to say 'this piece of memory here is needed as long as that piece of memory over there is needed'. The Samba people use this allocation strategy using a function called talloc. I have written my own implementation (halloc) which is a bit different from talloc:

* You can register functions to be called when a specific piece of memory is free'd. That means you can call free on memory not allocated using halloc when a halloc'd piece of memory is freed, which makes using halloc together with libraries and functions not specifically written for halloc much easier.

* Halloc overallocates memory, and uses the extra memory to fullfill smaller memory allocations. That means that doing lots and lots of very small memory allocations very close to free, both in memory usage and CPU time. In fish (http://roo.no-ip.org/fish) only one quarter of all calls to halloc actually result in an underlying call to malloc.

Most of the time, the scope of a halloc allocation is still a single functions lifetime. The major difference, however, is that you can specify _which_ function. You can send along a context as a parameter to another function, and all the memory allocations performed by the called function will use the supplied context as allocation scope. This takes C a huge step closer to the ease of use of automatically garbage collected languages when it comes to memory handling.

At least that has been my experience.


to post comments

Detecting kernel memory leaks

Posted Jun 24, 2006 12:01 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

The need for the registration function is mostly obviated by notifiers, AIUI. The halloc() function is rendered unnecessary by the slab allocator (that's what slabs are, blocks of memory containing many potential objects of the same type, initialized from a template and allocatable at lightning speed.)

Detecting kernel memory leaks

Posted Jul 19, 2006 15:55 UTC (Wed) by liljencrantz (guest, #28458) [Link]

Slabs are a performance hack to make some allocation patterns faster. This is completely different from halloc, which is a method for making memory deallocation significantly less cumbersome for the programmer. Both have the potential to waste less time and memory, but that is mainly a possible byproduct in the case of halloc.

Notifiers would work as a replacement for the halloc callback functions, but the result would be wordier and need more changes on existing code.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds