[lkml]   [2011]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] new cgroup controller "fork"
On 11/3/2011 3:25 PM, Glauber Costa wrote:
> On 11/03/2011 05:20 PM, Max Kellermann wrote:
>> On 2011/11/03 20:03, Alan Cox<> wrote:
>>> Sure - I'm just not seeing that a whole separate cgroup for it is
>>> appropriate or a good plan. Anyone doing real resource management needs
>>> the rest of the stuff anyway.
>> Right. When I saw Frederic's controller today, my first thought was
>> that one could move the fork limit code over into that controller. If
>> we reach a consensus that this would be a good idea, and would have
>> chances to get merged, I could probably take some time to refactor my
>> code.
>> Max
> I'd advise you to take a step back and think if this is really needed.
> As Alan pointed out, the really expensive resource here is already being
> constrained by Frederic's controller.

I think this really is a different knob that is nice to have as long as
it doesn't cost much. It's a way to set a max lifespan in a way that
isn't really addressed by the other controls. (I could absolutely be
missing something.)

I think Max explained the issue clearly enough.

It doesn't matter that the fork itself is supposedly so cheap.

It's still nice to have a way to say, you may not fork/die/fork/die/fork
in a race.

What's so unimaginable about having a process that you know needs a lot
of cpu and ram or other resources to do it's job, and you expressly want
to allow it to take as much of those resources as it can, but you know
it has no need to fork, so if it forks, _that_ is the only indication of
a problem, so you may only want to block it based on that.

Sure many other processes would legitimately fork/die/fork/die a lot
while never exceeding a few total concurrent tasks, and for them you
would not want to set any such fork limit. So what?


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