Why do the CFS chase fairness?
mobile.parmenides at gmail.com
Mon Sep 19 12:26:44 EDT 2011
> 2011/9/19 Mulyadi Santosa <mulyadi.santosa at gmail.com>:
> Hi :)
> Seriously, what I consider "more fair" is Con Kolivas BFS scheduler
> these days. No excessive "time slice weighting", just priority
> stepping and very strict deadline.
Hmm..., does that mean timeslice weighting introduce unfainess? If we
think fairness relies on each task not fetching more timeslice than
other tasks, the eaiest way to achieve fairness is to give every task
the same timeslice. But this way seemingly can not be considered as
fair. So, an exact definition of fairness will be appreciated.
> I took this chance to add: to maximize throughput too...
> well, if you have processess let's say A, B, C. A and B are CPU bound,
> C sleeps most of the times (let's say it's vim process running)
> If a scheduler implement very fair scheduling, then whenever user
> press a key in vim window, C should be kicked in ASAP and then run.
> However, as C yields its time slice, A or B should back ASAP too.
> If the scheduler is not really fair, then C should wait longer to be
> back running. But C should not be given too much time so A and B have
> more time to complete their number crunching works
Can I understand like this: each task advance its progress tinier than
traditional timeslice, which makes C has more chances to be selected
to preempt A or B owing to its higher priority? Higer priority makes
C's virtual time smaller than A and B.
More information about the Kernelnewbies