Re: Detailed Stack Information Patch [2/3]

[Stefani Seibold <stefani@seibold.net>]

Am Mittwoch, den 01.04.2009, 21:36 +0200 schrieb Ingo Molnar:
> * Stefani Seibold <stefani@seibold.net> wrote:
> 
> > +config PROC_STACK_MONITOR
> > + 	default y
> > +	depends on PROC_STACK
> > +	bool "Enable /proc/stackmon detailed stack monitoring"
> > + 	help
> > +	  This enables detailed monitoring of process and thread stack
> > +	  utilization via the /proc/stackmon interface.
> > +	  Disabling these interfaces will reduce the size of the kernel by
> > +	  approximately 2kb.
> 
> Hm, i'm not convinced about this one. Stupid question: what's wrong 
> with ulimit -s?
> 

To tell a long story short, you are right. After a quick investigation
of the glibc 2.9 library i figure out that this is also the default
stack size of a thread started with pthread_create().

> Also, if for some reason you dont want to (or cannot) enforce a 
> system-wide stack size ulimit, or it has some limitation that makes 
> it impractical for you - if we add what i suggested to the 
> /proc/*/maps files, your user-space watchdog daemon could scan those 
> periodically and report any excesses and zap the culprit ... right?

I think a user space daemon will be the a good way if the /proc/*/maps
or /proc/*/stack will provide the following information:

- start address of the stack
- current address of the stack pointer
- highest used address in the stack

> 
> 	Ingo

Stefani