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:"october@surriel.com">october@surriel.com</a> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 23 2003 - 22:00:12 EST