循环时间调度中的时间片

Question

If you have a very large (say too big) time slice for a round robin scheduler what kind of performance effect should I expect in the Operating System?

My only thought is that processes that require a lot of time would benefit but most processes use a small amount of time, so it would cause a delay in finishing all the smaller processes?

Example: timeslice of 50, and processes P1=400, P2=10, P3 = 150, P4 = 20, P5 = 10, P6 = 10

This is my best guess I am wondering if there is anything you guys could share as far as a time slice being too small or too large.

Answer 1

The problem with round robin is that tasks aren't equal.

For CPU bound tasks; if you've got an extremely important task and thousands of unimportant tasks, then all those unimportant tasks cripple the performance of the important task. For this case it doesn't matter how big the time slices are.

For IO bound tasks, round robin causes bad latency. If an important task unblocks (eg wakes up after calling "sleep()", receives file IO it was waiting for, etc) then it may have to wait for thousands of unimportant tasks to work their way through their time slices before the important task gets a chance to do anything. Reducing the time slice length will reduce the time it takes before the important task can start doing something useful, but will also reduce the amount of time the important task gets to do something useful.

Note: You might be tempted to "fix" this by making tasks that unblock go to the head of the list. In this case an important task can be starved forever just because unimportant tasks keep sleeping and waking up.

Essentially, round-robin is a steaming pile of "useless" and it won't matter what you do until you replace it with completely different scheduling algorithm that has at least some respect for the importance/priority of different tasks.

For an oversimplified example; you could have 3 different task priorities, where the OS only ever runs the highest priority tasks that it can (including making sure higher priority tasks preempt lower priority tasks immediately) and round-robin is used for tasks at the same priority. In this case, you could could have different time slice lengths for different priorities (eg high priority tasks only get 1 ms, medium priority tasks get 10 ms, low priority tasks get 125 ms).

For a "less oversimplified" example; you could have several completely different scheduling policies (eg one for real-time tasks, one for normal tasks, one for background/idle tasks) that all use different approaches (eg earliest deadline first, variable time slice, etc); where there's 256 tasks priorities for each scheduling policy.

Answer 2

From time slicing point of view, there are 2 extreme scenarios which decrease performance. If the time slice is:

1. Too big: causes small processes to wait for very long time when they could have finished much earlier had time slice been smaller. Also, this is not favorable for interactive processes which require smaller but frequent CPU time.
2. Too small: causes frequent context switches which amounts to significant overhead.

Historically, OS developers have worked hard to strike a balance in between these two extremes and there are various priority based algorithms which get imbibed with Round-robin for better performance.