What happens when time slices are too short or too long?

A context switch between two tasks takes a certain amount of time. Let’s say that there are two runnable tasks on a particular system. Each context switch will take about the same time, say 0.1ms. If there is a context switch every 10ms, then each task is left to run for 9.9ms, then out of every 1ms period, 99% is spent running the tasks and 1% is spent in context switches. If we increase the frequency of context switching to be every 1ms, then context switches waste 10% of the time. In the extreme case, if we increase again to have a context switch every 0.1ms, then the whole processor time is spent in context switches, there is no time left to run the applications. Thus, for performance, it is best to have context switches as rarely as possible. This increases the time that is available to actually run applications. However, if context switches are too rare, then there is a delay before an application can react to an external event. This is not a problem for a purely computational program, but it is a problem for a program that does input/output. For example, the frequency of context switches is only once per second, then computational tasks don’t waste time, but a network server may take up to one second to reply (or more if there are more than two tasks), an interactive program may take up to one second to react to a keypress, etc. Thus the operating system scheduler must find a balance between computational performance and reactivity. Sophisticated schedulers try to find out which tasks are computational and which ones are I/O-bound, and give I/O-bound tasks shorter but more frequent time slices and give computational tasks longer but less frequent time slices.