lkml.org 
[lkml]   [2009]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Detailed Stack Information Patch [2/3]
From
Date
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




\
 
 \ /
  Last update: 2009-04-02 23:23    [W:0.045 / U:0.368 seconds]
©2003-2014 Jasper Spaans. Advertise on this site