Re: Detailed Stack Information Patch [0/3]

[Stefani Seibold <stefani@seibold.net>]

Hi Andi,

Am Dienstag, den 31.03.2009, 17:49 +0200 schrieb Andi Kleen:
> Stefani Seibold <stefani@seibold.net> writes:
> >
> > - Get out of virtual memory by creating a lot of threads
> >  (f.e. the developer did assign each of them the default size)
> 
> The application just fails then? I don't think that needs
> a new monitoring tool.
> 

First, this patch is not only a monitoring tool. Only the last part 3/3
is the monitoring tool.

Patch 1/3 enhance the the proc/<pid>/task/<tid>/maps by the marking the
thread stack.

Patch 2/3 gives you an overview of the current process/thread stack
usage with the /proc/stackmon entry.

> > - Misuse the thread stack for big temporary data buffers
> 
> That would be better checked for at compile time
> (except for alloca, but that is quite rare)

Fine but it did not work for functions like:

void foo(int n)
{
	char buf[n*1024];

}

This is valid with gcc.

> 
> > - Thread stack overruns
> 
> Your method would be racy at best to determine this because
> you don't keep track of the worst case, only the current case.
> 
> So e.g. if you monitoring app checks once per second the stack
> could overflow between your monitoring intervals, but already
> have bounced back before the checker comes in.
> 

The Monitor is part 3/3. And you are right it is not a complete rock
solid solution. But it works in many cases and thats is what counts.

> Alternatively you could keep
> track of consumption in the VMA that has the stack,  but
> that can't handle very large jumps (like f() { char x[1<<30]; } )
> The later can only be handled well by the compiler.

Thats is exactly what i am doing, i walk through the pages of the thread
stack mapped memory and keep track of the highest access page. So i have
the high water mark of the used stack.

The patches are not intrusive, especially part 1.

> 

Stefani