Hi,
A good way to prevent memory leaks and simplify code is to reduce the use of
kmalloc for a certain class of situations. Specifically, I am referring to
blocks of code with the following:
bar(){
.
.
foo=kmallc
.
.
.
kfree(foo)
.
.
}
This sort of thing is best handled on the stack, but, of course, that has
critical flaws. A way to deal with this is to create a per-cpu kmalloc'ed
dynamically extended stack from which memory can be allocated. Then, most
allocations/deallocations are done in O(1) and memory fragmentation due to
lots of small allocation is avoided.
Furthermore, with the help of macros, memory leaks due to mid-function returns
and such can be completely avoided.
A survey of kernel code revealed a number of places where this methodology can
be applied.
-Alex Khripin
On Wed, 15 Jan 2003, Alex wrote:
> bar(){
> .
> foo=kmallc
> .
> kfree(foo)
> This sort of thing is best handled on the stack,
The kernel stack is 8 kB per process.
> A way to deal with this is to create a per-cpu kmalloc'ed dynamically
> extended stack from which memory can be allocated.
That only works if this kernel thread doesn't schedule.
If you schedule, you'd end up with multiple processes
wanting to use the same pool, or with a process moving
from one pool to the other (without the ability to
take its data with it).
> Furthermore, with the help of macros, memory leaks due to mid-function
> returns and such can be completely avoided.
I'm doubtful, but if you think you know a way to pull
it off I'm curious to see it ...
cheers,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>