* Linus Torvalds <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
