On Fri, 04 Nov 2011 11:03:41 +0800 Li Zefan <lizf@xxxxxxxxxxxxxx> wrote: > 于 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<alan@xxxxxxxxxxxxxxxxxxx> 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)." > > (http://lkml.org/lkml/2011/10/19/468) > > The last sentence suggests he might like this fork controller. > Hmm, IMHO, this feature may have some use case. But I don't like to have both of fork/task controller at the same time and need to mount 2 of them. How about accounting the number of fork or fork-speed in 'task' controller and add 'notifier' as memcg's memory usage notification ? (Or fork-limit in task controller.) BTW, what is performance impact to add lock/counter in fork/die path ? Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
