Re: Detailed Stack Information Patch [2/3]

Stefani Seibold
2009-04-02T21:20:43Z

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