[lkml]   [2010]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] fs: limit maximum concurrent coredumps
    On Mon, 21 Jun 2010 18:41:16 -0700
    Andrew Morton <> wrote:

    > On Mon, 21 Jun 2010 18:23:03 -0700 (PDT) Roland McGrath <> wrote:

    > > That won't make your crashers each complete quickly, but it will prevent
    > > the thrashing. Instead of some crashers suddenly not producing dumps at
    > > all, they'll just all queue up waiting to finish crashing but not using any
    > > CPU or IO resources. That way you don't lose any core dumps unless you
    > > want to start SIGKILL'ing things (which oom_kill might do if need be),
    > > you just don't die in flames trying to do nothing but dump cores.
    > A global knob is a bit old-school. Perhaps it should be a per-memcg
    > knob or something.

    Hmm, in my desktop, it seems coredump in a group is charged against
    root cgroup. (not against the group it belongs to.)
    This seems strange.....I've chased why...for 2 hours. I noticed

    [root@bluextal kamezawa]# cat /proc/sys/kernel/core_pattern
    |/usr/libexec/abrt-hook-ccpp /var/cache/abrt %p %s %u %c
    This is fedora-12.

    Then, for recent distros, doing "coredump" with some limited resource may
    be a job of abrt program. It can make use of I/O cgroup + direct I/O.

    If a kernel help is necesary, this helper function should work in
    the caller's cgroup, maybe.


     \ /
      Last update: 2010-06-22 10:57    [W:0.022 / U:14.744 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site