2011/9/26 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
Hi :)
Actually, the CFS scheduler which is a new scheduler in Linux kernel also does the same thing. But, I think this way does not fit with scheduler's principle.
remember the keyword you ask? "fairness"? that is being fair to all processes.... but since, there are always more processes than processors, unfairness always happen.....
In fact, I am interested in the length of timeslice rather than fairness at this point. :-)
This way ensures lower latency. It is also necessary that CPU-bound processes are to be allocated longer timeslice to improve throughput owing to less process switch costs. That means lower priority processes (CPU-bound) should be allocated longer timeslice, whichs obviously conflicts with the actual practice taken by the Linux's scheduler. Any explanation?
What you refer initially is the time when time slice assignment is strictly derived from the static/nice level. So e.g process with nice level 0 has lesser time slice that nice level -5.
But as you can see, situation change dynamically during run time, thus static prio must be taken into dynamic priority. And dynamic priority itself, must take another factor for time slice calculation. Here, sleep time comes into play.
Ok, suppose that there is a CPU-bound process and a I/O-bound process, both of them are allocated the same nice level 0. After some time, the I/O-bound process will receive higher dynamic priority owing to its frequent sleeping. Now that the I/O-bound process more like to sleep, why does the scheduler give it longer timeslice? After all, it really does not need more time. On ther other hand, the CPU-bound process will receive lower dynamic priority as its punishment because it costs more CPU time. Lower dynamic priority indicates this process is more 'CPU-bound', that is this process need more CPU time. If the scheduler allocates longer timeslice for this process, the frequency of process switch will be reduced. I think that will help to improve throughput of the entire system.