Peter Williams wrote:
Peter Williams wrote:
Ingo Molnar wrote:
your suggestion concentrates on the following scenario: if a task
happens to schedule in an 'unlucky' way and happens to hit a busy
period while there are many idle periods. Unless i misunderstood your
suggestion, that is the main intention behind it, correct?
You misunderstand (that's one of my other schedulers :-)). This one's
based on the premise that if everything happens as the task expects it
will get the amount of CPU bandwidth (over this short period) that
it's entitled to. In reality, sometimes it will get more and
sometimes less but on average it should get what it deserves. E.g. If
you had two tasks with equal nice and both had demands of 90% of a CPU
you'd expect them each to get about half of the CPU bandwidth. Now
suppose that one of them uses 5ms of CPU each time it got onto the CPU
and the other uses 10ms. If these two tasks just round robin with
each other the likely outcome is that the one with the 10ms bursts
will get twice as much CPU as the other but my proposed method should
prevent and cause them to get roughly the same amount of CPU. (I
believe this was a scenario that caused problems with O(1) and
required a fix at some stage?)
Another advantage of this mechanism is that, all else being equal, it
will tend to run tasks that use short bursts of CPU ahead of those that
use long bursts and this tends to reduce the overall time spent waiting
for CPU by all tasks on the system which is good for throughput. I.e.
in general, a task that tends to use short bursts of CPU will make other
tasks wait less time than will one that tends to use long bursts.
So this means that you were right and it is good in the scenario that
you suggested even though that wasn't the motivation behind the design.
This means that this scheduler should be good for improving latency on
servers that aren't fully loaded as well as providing good fairness and
responsiveness when the system is fully loaded. (Fingers crossed.)
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
