Kernel thread stack usage

[Julian Elischer]

Kostik Belousov wrote:
> On Sun, Nov 11, 2007 at 12:25:51PM +0200, Alexander Motin wrote:
>>> As known in netgraph susbystem information passing from one node to
>>> another by direct function calls without queueing. It gives performance
>>> bonuses, but it also gives permanent stack overflow risk on complicated
>>> graphs. Netgraph is still have a queues and able to use them when asked,
>>> but now queueing is a flag which should be controlled by sending node. I
>>> think it would be good to implement some algorithm which could monitor
>>> stack usage on each call and enforce queueing when stack usage become
>>> critical.
>>>
>>> The question is: is there correct way to somehow get current kernel
>>> thread stack usage or just a stack base address?
>> Digging kernel with a dirty hands I have found the way which looks like 
>> working. I have briefly tested it on i386.
>>
>> printf("%p, %p. Used %d of %d.\n", &var,
>>   (char *)td->td_kstack + td->td_kstack_pages * PAGE_SIZE,
>>   (char *)td->td_kstack + td->td_kstack_pages * PAGE_SIZE -
>>     (char *)&var,
>>   td->td_kstack_pages * PAGE_SIZE);
>>
>> 'var' here is a name of some local variable.
>>
>> Can anybody comment correctness of this way or propose another one?
> 
> Most of the time, you will get the correct value. But, see the
> vm_thread_new_altstack() in vm/vm_glue.c.

Also, and others may want to pipe in on this, it might go in
machine dependent code because it is *theoretically* we could 
port one day to a machine with an upward growing stack.

It has happened in the distant past but it has been growing less 
likely in the recent past. With the advent of truely HUGE address spaces,
it becomes feasible again. (which of course doesn't mean someone will do it).

I guess that if someone ports to such a machine, this would be the 
least of his problems, so I guess it's not a factor.