Re: 4k stacks in 2.6

Arjan van de Ven
2004-05-27T14:03:45Z

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

On Thu, May 27, 2004 at 03:59:30PM +0200, Andrea Arcangeli wrote:
> On Thu, May 27, 2004 at 02:45:51PM +0200, Ingo Molnar wrote:
> > are a bit belated. I only reacted to Andrea's mail to clear up apparent
> > misunderstandings about the impact and implementation of this feature.
>
> note that there is something relevant to improve in the implementation,
> that is the per-cpu irq stack size should be bigger than 4k, we use 16k
> on x86-64, on x86 it should be 8k. Currently you're decreasing _both_
> the normal kernel context and even the irq stack in some condition.
> There's no good reason to decrease the irq stack too, that's cheap, it's
> per-cpu.

In theory you are absolutely right, problem is the current macro..... it's
SO much easier to have one stacksize everywhere (and cheaper too) for
this... (and it hasn't been a problem so far, esp since the softirq's have
their own stack, irq handlers seem to be all really light on the stack
already since they punt all the heavy lifting to tasklets etc.
Tasklets don't recurse stack wise, and have their own stack, so that ought
to be fine.

On x86_64 you have the PDA for current so that's not a problem, and you can
do the bigger stacks easily but for x86 you don't...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]