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.021 / U:60.528 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site