We have mentioned what a context switch is ”a switch from one executing thread to another thread. The reasons why a context switch would occur are listed in Table 11-3.
Table 11-3. Reasons for a Context Switch
Forced
Voluntary
A timeslice expires .
A thread goes to sleep.
A real-time thread becomes runnable. We will relinquish the CPU (almost) immediately.
A thread is stopped .
A thread with a higher priority becomes runnable. We will relinquish the CPU at the end of this clock tick.
A thread exits.
A thread returns to user mode after a system call or a trap.
The thread has reached a special area of code in the kernel known as a preemption point.
We have mentioned this notion of a timeslice . This is the maximum amount of time a thread is allowed to run before the CPU is given to the next thread. If there are no other runnable threads, the previous thread is allowed to regain control of the CPU for another timeslice . A timeslice occurs every 100 milliseconds . There are other intervals at which the kernel will perform housekeeping activities other than just context switching:
10 milliseconds (1 tick) : The system clock ticks every 10 milliseconds. This is an important time because it is at this time that we attribute the current cumulative time to the thread currently on the CPU. The statistics that are gathered include process as well as per-processor statistics that will be used for multiprocessor load balancing. At this time, if there is a more deserving thread that is runnable, we can context switch to it; otherwise , the current thread is allowed to continue executing. A real-time thread can interrupt a processor during this time period. If interrupted , the processor will context switch to real-time thread. This makes for an interesting situation. It is still conceivable that a thread relinquishes the CPU to another thread before the end of a clock tick. The remaining time is then attributed to the new thread when process statistics are gathered at the time of the next tick. Recent changes to the kernel statistics gathering code have tried to minimize this happening, but it is still possible.
40 milliseconds (4 ticks) : The kernel will recalculate the priority of all runnable and running threads. The statistics gathered ”every tick + the current priority + process nice value ”are used to recalculate the priority of the current threads. As a thread runs, its priority will decay over time. The priority of real-time threads never decays. If after the recalculation a thread has a higher priority than the currently executing thread, it will be context switched onto the CPU.
100 milliseconds (10 ticks) : This is the end of a timeslice . The current thread will be context switched off the CPU to decide which thread is most eligible to get the CPU next. If there are no other runnable threads, or the current thread still has the highest priority, it will regain the CPU.
NOTE : timeslice is a configurable kernel parameter. It is specified as a number of ticks (default = 10). Increasing timeslice can improve performance of compute- intensive applications at the expense of an online system responsiveness. If you are unsure whether your overall system behavior would benefit from this, it is strongly advised that you leave timeslice at its default value. The maximum you can set timeslice to is 0x7fffffff 8 months, but dont even think about it.
1 second (100 ticks) : The priority of every thread is recalculated every 1 second with the help of the statdaemon process. At this time, the load average for every processor is recalculated in order to establish whether a processor is being overloaded. A number of internal kernel routines will ensure that threads are spread evenly over processors within a locality domain to avoid starvation occurring on any one processor.
As we can see, process priority is the governing factor as to whether a thread is given the CPU. Normal thread priority decays over time. The idea is that we want to give an equal amount of time to all threads on the system.
8 months, but dont even think about it. 