Kernel thread stack usage

[Alexander Motin]

Marcel Moolenaar wrote:
> Yes. A good place would be cpu_switch in this case, because
> the processor flushes the dirty stacked registers onto the
> register stack only when it "feels" like it or when instructed
> to do so. In practice this means that while the stacks may
> have run into each other based on the pointers, the memory
> corruption (sec) often happens in cpu_switch where we force
> the processor to flush the dirty stacked registers.
> 
> In other words: a thread is expected in the common case to
> encounter the corruption until the next switch-in, but could
> in case of excessive use of either or both stacks encounter
> it on function boundaries (function calls and/or returns).
> 
> As a side-note: The implementation of kernel stack guard pages
> is just as meaningless for ia64. As a first improvement, you
> want guard pages both at the top and at the bottom and not just
> at the bottom. Secondly, you want to be able to protect each
> stack running into each other. However, putting a guard page
> somewhere in the middle may not be the right thing, because
> different threads may require different ratios...

If I understand you right you are talking about stack overflow/memory 
corruption detection mechanism. But I am speaking just about getting 
stack usage statistics.

When Netgraph subsystem passes packet from one node to another it can or 
make direct function call or use queues. Direct call is preferred for 
the performance reasons, but numerous subsequent calls may cause stack 
overflow. To optimize behaviour I need some platform independent 
mechanism to get current stack usage to check is it reached some defined 
level, for example 50%, or not. Definitely such method still keeps 
overflow possible, but it will reduce it's probability as much as possible.

For i386 platform we have registers pointing current stack head. To 
simplify my example I have used address of local variable for that. 
Probably for ia64 we should just use one more register or algorithm to 
take into account second stack growing upward.

-- 
Alexander Motin