[lkml]   [2010]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC/RFT PATCH v3] sched: automated per tty task groups
    On Sun, Nov 14, 2010 at 3:43 PM, Mike Galbraith <> wrote:
    > Not only. pinned tasks would stay in their autogroup until somebody
    > moved them to a cgroup.  Them wandering back over time would be fine,
    > and all but pinned tasks will.

    But why is a problem?

    That's kind of my point. Why do we care about some special case that
    (a) likely doesn't happen and (b) even if it happens, what's the
    problem with it happening?

    Let me put it this way: the autogroup thing modifies the scheduler in
    some subtle ways, but it doesn't make any _semantic_ difference. And
    it's not like enabling/disabling autogroup scheduling is something
    critical to begin with. It's a heuristic.

    THAT is why I think it's so silly to try to be so strict and walk over
    all processes while holding a couple of spinlocks.

    Ok, so you disable autogroups after having used them, _and_ having
    done some really specific things, and some processes that used to be
    in a group may end up still scheduling in that group. Why care? It's
    not like random people can enable/disable autogroup scheduling and try
    to use this as a way to get unfair scheduling.

    In fact, I'd go as far as saying that for the tty-based autogroup
    scheduling, if you want the autogroup policy to take effect, it would
    be perfectly ok if it really only affected the actual group
    _allocation_. So when you turn it on, old tty associations that
    existed before autogroup being turned on would not actually be in
    their own groups at all. And when you turn it off, existing tty groups
    would continue to exist, and you'd actually have to open a new window
    to get processes to no longer be part of any autogroup behavior.

    See what I'm saying? I still think you're bending over backwards to be
    "careful" in ways that don't seem to make much sense to me.

    Now, if there is some really fundamental reason why processes _have_
    to be disassociated with the group when the autogroup policy changes,
    that would be a different issue. If the scheduler oopses when it hits
    a process that was in a tty autogroup but autogrouping has been turned
    off, _that_ would be a reason to say "recalculate everything when you
    disable/enable policy groups". But I don't think that's the case.

    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: 2010-11-15 01:17    [W:0.023 / U:19.280 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site