lkml.org 
[lkml]   [2010]   [Nov]   [15]   [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 Mon, Nov 15, 2010 at 2:41 PM,  <Valdis.Kletnieks@vt.edu> wrote:
    >
    > So the set of all tasks that never call proc_set_tty() ends up in the same one
    > big default group, correct?

    Well, yes and no.

    Yes, that's what the code currently does. But I did ask Mike (and he
    delivered) to try to make the code look and work in a way where the
    whole "tty thing" is just one of the heuristics.

    It's not clear exactly what the non-tty heuristics would be, but I do
    have a few suggestions:

    - I think it might be a good idea to associate a task group with the
    current "cred" of a process, and fall back on it in the absense of a
    tty-provided one.

    Now, for desktop use, that probably doesn't often matter, but even
    for just the desktop it would mean that "system daemons" would at
    least get a group of their own, rather than be grouped with
    "everything else"

    (As is, I think the autogroup thing already ends up protecting
    system daemons more than _not_ having the autogroup, since it will
    basically mean that a "make -j64" won't be stealing all the CPU time
    from everybody else - even if the system daemons all end up in that
    single "default" group together with the non-tty graphical apps.)

    - I suspect we could make kernel daemons be a group of their own.

    > Do we have any provisions for making sure that if
    > a user has 8 or 10 windows open doing heavy work, the default group (with a lot
    > of important daemons/etc in it) doesn't get starved with only a 1/10th share of
    > the CPU? Or am I missing something here?

    I think you're missing the fact that without the autogroups, it's
    _worse_. If you do "make -j64" without autogroups, those important
    daemons get starved by all that work. With the autogroups, they end up
    being protected by being in the default group.

    So the fact that they are in the default group with lots of other
    users doesn't hurt, quite the reverse. User apps are likely to be in
    their own groups, so they affect system apps less than they do now.

    But I do agree that we might be able to make that all much more explicit.

    Linus
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-11-16 00:29    [W:0.039 / U:178.288 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site