Re: 2.6.6-rc3-mm2 (4KSTACK)

[Steve Lord <lord@xfs.org>]

Arjan van de Ven wrote:
>>Is it less pain than making something like a memory allocation which comes
>>out of a deep stack? Say, nfs server -> filesystem -> lvm/raid -> fiber channel,
>>which itself does something like a writepage into an nfs filesystem and ends
>>up in the networking stack? OK, getting back into the filesystem on a
>>memory allocation from the block layer should not happen, but you could
>>certainly be down in
> 
> 
> it's not really much different than the 2.4 kernel already has.
> In 2.4 you have a 8Kb stack of which
> 
> First 1600 bytes (+/-) are for the task struct
> about 4Kb of user context stack
> 
>>= 2Kb stack which is needed for irq context (both soft and hard)
> 
> 
> In 2.6 with this patch you have
> 
> 32 bytes for thread info
> 4Kb minus 32 bytes for context stack
> SEPARATE softirq stack of 4K
> SEPARATE hardirq stack of 4K
> 
> so in a way you have MORE stack space than in 2.4.
> 
> Now I'll fully admit the 2Kb is somewhat of a stochast, you only hit it
> if you have iptable rules and 2 nic irq's arriving on the same cpu at an
> unfortionate moment, but that doesn't mean it's a safe situation.
> 

I agree with that, but that combination had a heck of a lot of soak time
on it. This stack crunching exercise is happening fairly early on in a
stable kernel series, that makes me nervous. A lot of new code showed up
in the meantime during 2.5 development which changed many of these
code paths.

You can do static code analysis and say which functions are stack hogs and
rework them, but the dynamic analysis is really hard to do for all possibly
combinations. Doing the dynamic analysis on someones production fileserver may
not be the wisest move ever made.

Steve