lkml.org 
[lkml]   [2007]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]

    * Linus Torvalds <torvalds@linux-foundation.org> wrote:

    > The fact is:
    >
    > - "fairness" is *not* about giving everybody the same amount of CPU
    > time (scaled by some niceness level or not). Anybody who thinks
    > that is "fair" is just being silly and hasn't thought it through.

    yeah, very much so.

    But note that most of the reported CFS interactivity wins, as surprising
    as it might be, were due to fairness between _the same user's tasks_. In
    the typical case, 99% of the desktop CPU time is executed either as X
    (root user) or under the uid of the logged in user, and X is just one
    task. Even with a bad hack of making X super-high-prio, interactivity as
    experienced by users still sucks without having fairness between the
    other 100-200 user tasks that a desktop system is typically using.

    'renicing X to -10' is a broken way of achieving: 'root uid should get
    its share of CPU time too, no matter how many user tasks are running'.
    We can do this much cleaner by saying: 'each uid, if it has any tasks
    running, should get its fair share of CPU time, independently of the
    number of tasks it is running'.

    In that sense 'fairness' is not global (and in fact it is almost _never_
    a global property, as X runs under root uid [*]), it is only the most
    lowlevel scheduling machinery that can then be built upon. Higher-level
    controls to allocate CPU power between groups of tasks very much make
    sense - but according to the CFS interactivity test results i got from
    people so far, they very much need this basic fairness machinery
    _within_ the uid group too. So 'fairness' is still a powerful lower
    level scheduling concept. And this all makes lots of sense to me.

    One purpose of doing the hierarchical scheduling classes stuff was to
    enable such higher scope task group decisions too. Next i'll try to
    figure out whether 'task group bandwidth' logic should live right within
    sched_fair.c itself, or whether it should be layered separately as a
    sched_group.c. Intutively i'd say it should live within sched_fair.c.

    Ingo

    [*] There are distributions where X does not run under root uid anymore.
    -
    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: 2007-04-18 19:53    [W:0.022 / U:60.268 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site