Context Switch questions: What part of the OS is involved in managing the Context Switch?

3.5k Views Asked by At

I was asked to anwer these questions about the OS context switch, the question is pretty tricky and I cannot find any answer in my textbook:

  1. How many PCBs exist in a system at a particular time?
  2. What are two situations that could cause a Context Switch to occur? (I think they are interrupt and termination of a process,but I am not sure )
  3. Hardware support can make a difference in the amount of time it takes to do the switch. What are two different approaches?
  4. What part of the OS is involved in managing the Context Switch?
3

There are 3 best solutions below

0
Mihai Maruseac On
  1. There can be any number of PCBs in the system at a given moment in time. Each PCB is linked to a process.
  2. Timer interrupts in preemptive kernels or process renouncing control of processor in cooperative kernels. And, of course, process termination and blocking at I/O operations.
  3. I don't know the answer here, but see Marko's answer
  4. One of the schedulers from the kernel.

enter image description here

0
Ankur On

The scheduler is the part of the operating systems that manage context switching, it perform context switching in one of the following conditions:
1.Multitasking

2.Interrupt handling

3.User and kernel mode switching

and each process have its own PCB

0
marko On

3: A whole number of possible hardware optimisations

  • Small register sets (therefore less to save and restore on context switch)
  • 'Dirty' flags for floating point/vector processor register set - allows the kernel to avoid saving the context if nothing has happened to it since it was switched in. FP/VP contexts are usually very large and a great many threads never use them. Some RTOSs provide an API to tell the kernel that a thread never uses FP/VP at all eliminating even more context restores and some saves - particularly when a thread handling an ISR pre-empts another, and then quickly completes, with the kernel immediately rescheduling the original thread.
  • Shadow register banks: Seen on small embedded CPUs with on-board singe-cycle SRAM. CPU registers are memory backed. As a result, switching bank is merely a case of switching base-address of the registers. This is usually achieved in a few instructions and is very cheap. Usually the number of context is severely limited in these systems.
  • Shadow interrupt registers: Shadow register banks for use in ISRs. An example is all ARM CPUs that have a shadow bank of about 6 or 7 registers for its fast interrupt handler and a slightly fewer shadowed for the regular one. Whilst not strictly a performance increase for context switching, this can help ith the cost of context switching on the back of an ISR.
  • Physically rather than virtually mapped caches. A virtually mapped cache has to be flushed on context switch if the MMU is changed - which it will be in any multi-process environment with memory protection. However, a physically mapped cache means that virtual-physical address translation is a critical-path activity on load and store operations, and a lot of gates are expended on caching to improve performance. Virtually mapped caches were therefore a design choice on some CPUs designed for embedded systems.