lkml.org 
[lkml]   [2010]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC/RFT PATCH v3] sched: automated per tty task groups
    On Tue, Nov 16, 2010 at 11:13 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
    >
    > Its cpu-controller only, and then only for SCHED_OTHER tasks which are
    > proportionally fair.

    Well, it's _currently_ CPU controller only. People have already
    wondered if we should try to do something similar for IO scheduling
    too.

    So the thing I think is worth keeping in mind is that the "per-tty
    scheduling group" is really just an implementation issue. There is
    absolutely no question that it can't be about more than just
    scheduling, and that it can't be about more than just tty's also.

    And an important thing to keep in mind is that "user interfaces are
    bad". The thinner the interface, the better. One of the reasons I
    really like autogroup is that it has _no_ interface at all. It's very
    much a heuristic, and it has zero user interface (apart from the knob
    that turns it on and off, of course). That is a great feature, because
    it means that you cannot break the interface. You will never need to
    have applications that have special linux-specific hooks in them, or
    system daemons who have to touch magical /proc files etc.

    One of the problems I found annoying when just testing it using the
    plain cgroup interface (before the patch) was the resource management.
    You needed root, and they actually made sense requiring root, because
    I don't think we _want_ to allow people creating infinite numbers of
    cgroups. Vivek's "trivial patch" (shell script) is a major DoS thing,
    for example. Letting normal users create cgroups willy-nilly is not a
    good idea (and as Vivek already found out, his trivial script leaks
    cgroups in a pretty fundamental way).

    The tty approach is somewhat self-limiting in that it requires you to
    get the tty to get an autogroup. But also, because it's very much a
    heuristic and doesn't have any user-visible interfaces, from a kernel
    perspective it's wonderful. There are no "semantics" to break. If it
    turns out that there is some way to create excessive cgroups, we can
    introduce per-user limits etc to say "the heuristic works up to X
    cgroups and then you'll just get your own user group". And nobody
    would ever notice.

    So doing things automatically and without any user interface is about
    _more_ than just convenience. If it can be done that way, it is
    fundamentally better way to do things. Because it hides the
    implementation details, and leaves us open to do totally different
    things in the end.

    For example, 'cgroups' itself is pretty heavy-weight, and is really
    quite smart. Those things nest, etc etc. But with the "it's just a
    heuristic", maybe somebody ends up doing a "simplified non-nesting
    grouping thing", and if you don't want the whole cgroup thing (I have
    always answered no to CONFIG_CGROUPS myself, for example), you could
    still do the autogrouping. But you could _not_ cleanly do the
    /proc/sys/cgroup/user scripting, because your implementation is no
    longer based on the whole cgroups thing.

    Now, will any of this ever happen? I dunno. I doubt it will matter.
    But it's an example of why I think it's such a great approach, and why
    "it just works" is such an important feature.

    Linus

    Linus


    \
     
     \ /
      Last update: 2010-11-16 20:47    [W:4.178 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site