On Fri, 8 Feb 2002, Richard B. Johnson wrote:
> Could someone please tell me why you should make a function call to
> allocate, and then later on free, some temporary space for variables
> when allocation on the stack involves simply subtracting a value,
> calculated by the compiler at compile-time, from the stack-pointer?
because if you need that much stack space then you shouldnt care about
kmalloc() overhead anymore.
> This takes 42 clocks, not including the thousands used up by kmalloc
> and kfree.
kmalloc()+kfree() is not thousands. At least on SMP it has a nice frontend
cache and batch allocator component, which makes it much cheaper.
32 bytes you can allocate on the stack no problem. If you need to allocat
and *fill* 2K then kmalloc() overhead will not matter to you.
> If the kernel does not provide sufficient stack-space for small
> buffers and structures, it is a kernel problem, not a driver-coding
> problem. [...]
we will not add significant overhead to *every part* of the kernel just to
keep a ridiculously large stack around for those few drivers who should
use kmalloc() to begin with. And believe me, some people will then want to
do recursion on the stack and would complain even about a 1MB stack. There
is a limit to draw, and on Linux it's 'no bigger than a few hundred bytes,
allocate dynamically otherwise'.
Ingo
-
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 : Fri Feb 15 2002 - 21:00:20 EST