[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.109 / U:0.208 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site