Re: [PATCH] fs: limit maximum concurrent coredumps

[Roland McGrath <roland@redhat.com>]

A core dump is just an instance of a process suddenly reading lots of its
address space and doing lots of filesystem writes, producing the kinds of
thrashing that any such instance might entail.  It really seems like the
real solution to this kind of problem will be in some more general kind of
throttling of processes (or whatever manner of collections thereof) when
they got hog-wild on page-ins or filesystem writes, or whatever else.  I'm
not trying to get into the details of what that would be.  But I have to
cite this hack as the off-topic kludge that it really is.  That said, I do
certainly sympathize with the desire for a quick hack that addresses the
scenario you experience.

For the case you described, it seems to me that constraining concurrency
per se would be better than punting core dumps when too concurrent.  That
is, you should not skip the dump when you hit the limit.  Rather, you
should block in do_coredump() until the next dump already in progress
finishes.  (It should be possible to use TASK_KILLABLE so that those dumps
in waiting can be aborted with a follow-on SIGKILL.  But Oleg will have to
check on the signals details being right for that.)

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.


Thanks,
Roland