[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/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.

     \ /
      Last update: 2011-11-03 22:57    [W:0.025 / U:8.272 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site