[lkml]   [2011]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] new cgroup controller "fork"
On 2011/11/03 19:21, Alan Cox <> wrote:
> > After little discussion, nobody seemed to be interested in it, and
> > nobody merged it. I reposted it today, not knowing somebody else had
> > come up with a similar idea meanwhile.
> I don't really see a meaningful use case for this. Why should millions of
> users have this stuff in their kernel. What's the general purpose use
> case we should all be excited about ?

Putting a reasonable limit on jobs that are expected to run only for a
limited amount of time, with a limited amount of total resources. For
example: CGI, cron jobs, backup, munin plugins, virus scanners and
other email filters, procmail, ... - when the job is done, the group
can be deleted, and new instances will run in a new group.

With just RLIMIT_NPROC or task_counter, you can limit the total number
of processes, but it will not stop a fork bomb - it will only slow it
down. The fork bomb will still bounce between 1 and the limit, and
consume lots of resources for forking and exiting.

(Glauber: the above should answer your last email, too)

Similar existing feature: RLIMIT_CPU. Millions of users have it in
their kernels, but nobody uses it nowadays. And it's not even

Btw. I have no problem with maintaining this patch (and a whole bunch
of others) in my proprietary git repository at work forever. They're
very useful for my employer. I'm just trying to be a good citizen by
sharing them.


 \ /
  Last update: 2011-11-03 19:53    [W:0.067 / U:0.136 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site