Context Switching
| Depends on | Scheduler • Context |
|---|
An active process, whether running, ready or blocked, has its own context. In a running process this will be occupying the hardware resources, including the (or ‘a’) processor, MMU etc; other process’s contexts will be held in the process control blocks (PCBs), spare memory (not immediately accessible) or, ultimately, on disk backing store.
Every so often a running process is paused and evicted from the processor, to give another process a turn. This can be caused by:
- The running process completing and terminating.
- The running process becoming blocked attempting to I/O; this includes deliberate pausing for a time with a
sleep()call. - The runnning process deliberately yielding to let another process have a turn.
- An exception such as a page fault.
- this, in turn would lead to a blockage on I/O.
- An error such as a segmentation fault.
- Pre-emption by a time-slicing interrupt, if that process has been running “long enough”.
Notice that all of these are exceptions which have caused operaing system entry.
When there is a change of process state the scheduler needs to perform a context switch, ‘removing’ the running context from the hardware and replacing it with another. Here’s a more complicated example, including some I/O calls. The processor activity is highlighted, with the operating system in yellow and the user application in orange. Note, the operating system is entered both by system calls and interrupts; a system call may then call the scheduler, but doesn’t always.
A context switch will necessitate:
- saving the processor (“core”) registers – perhaps within the current Process Control Block (PCB) which is an operating system record.
- choosing (“scheduling”) a new process or thread.
- loading the new process’ state (from its PCB).
For a thread switch that may be enough. For a process switch there is more to change.
- the memory management page tables.
There will probably be cached information, some of which requires ‘flushing’ back to the memory before the new process starts to cache its data.
If the computer is quite busy, its physical memory may be fairly full; changing processes may (indirectly) cause extra paging, too. You may have observed this as a slowing down in your own computer’s responses.
Context switching is therefore quite an expensive operation.
More details
In particular, contrasting the difference in effort needed to switch processes and threads.
Process switching
Registers
The fundamental state held within the processor always needs to be saved (e.g.) into the process’ memory space and the ‘new’ process’ has to be loaded.
An optimisation is sometimes possible by deferring some state changes until it is known they are necessary. For example, as many processes will never use floating point operations, the floating point registers may not be loaded until it is known they are needed. (In such a case the FPU can be turned ‘off’, causing an exception if it is needed. This is similar, in principle, to the ‘trick’ of marking a virtual memory page as ‘invalid’ to see if it is wanted.) Such optimisations can save time at the expense of considerable extra complexity for the scheduler.
Memory management
The page tables probably occupy a significant memory space. However it is usually possible to keep a selection of alternative page tables in physical memory and change them simply by redefining a single pointer (Page Table Base) to the structure for the currently running process.
Any optimisation of the translation via a TLB is invalidated by changing the tables. As with caches (below) the TLB needs to be flushed and allowed to reload as the new process runs.
Resources
The lists of resources will be in physical memory – probably maintained in the operating system’s space – so this is not too much of an issue on a simple process switch.
On process termination – maybe in an ‘untidy’ fashion due to a process crash (or sloppy programming!) – the operating system should probably ‘tidy up’ and reclaim any resources owned by the process. This includes memory, I/O devices, files etc.
Caches
The contents of any caches which are specific to the process will be obsolete. If the level-1 cache has used virtual addresses (likely in any high-performance system) it needs to be flushed. (This may entail copying data back down the memory hierarchy.) This can be time consuming. It is then invalidated – a process which can be quick in itself.
Then it needs to refill gradually as the next process runs. A newly restarted process is therefore slow until it has restored its cache contents.
Thread switching
Thread switching still needs to replace the immediate processor register state.
Switching the memory map (and its consequent impact on the cache efficiency) is likely to be the greatest performance impact of context switching. In some circumstances this can be avoided whilst retaining the advantages of independent threads of execution.
In a multithreaded system several threads share the same view of memory; switching is therefore confined to changing the ‘register’ state held in the processor. Thus, switching between threads in the same process is much cheaper than full process switches.
For very enthusiastic people …
… a little article on partial context switching.
| Also refer to: | Operating System Concepts, 10th Edition: Chapter 3.2.3, pages 114-115 |
|---|
