Messages in this thread | | | Date | Thu, 3 Nov 2011 19:54:55 -0200 | From | Glauber Costa <> | Subject | Re: [PATCH] new cgroup controller "fork" |
| |
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<alan@lxorguk.ukuu.org.uk> 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.
| |