Hi, > 2011/9/19 Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>: > 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. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
