[lkml]   [2011]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] new cgroup controller "fork"
于 2011年11月04日 05:54, Glauber Costa 写道:
> On 11/03/2011 06:13 PM, Brian K. White wrote:
>> 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.
> He did, indeed.
>> 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?
> As I said previously, he knows his use cases better than anyone else.
> If a use case can be found in which the summation of cpu+task controllers is not enough, and if this is implemented as an option to the task controller, and does not make it:
> 1) confusing,
> 2) more expensive,
> then I don't see why not we shouldn't take it.

Quoted from Lennart's reply in another mail thread:

"Given that shutting down some services might involve forking off a few
things (think: a shell script handling shutdown which forks off a couple
of shell utilities) we'd want something that is between "from now on no
forking at all" and "unlimited forking". This could be done in many
different ways: we'd be happy if we could do time-based rate limiting,
but we'd also be fine with defining a certain budget of additional forks
a cgroup can do (i.e. "from now on you can do 50 more forks, then you'll
get EPERM)."


The last sentence suggests he might like this fork controller.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-11-04 04:05    [W:0.073 / U:24.592 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site