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

> On Mon, 21 Jun 2010 18:23:03 -0700 (PDT) Roland McGrath <roland@redhat.com> 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.

Regards,
-Kame



\
 
 \ /
  Last update: 2010-06-22 10:57    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean