Preserving the state needed to resume
Pausing a task requires preserving the state needed for later continuation, such as registers, program location, and stack position. Restoring another task’s state directs the processor to that task’s own continuation.
The OSTEP account illustrates this through register and kernel-stack handling. Exact saved contents and the division between hardware and software vary by architecture and operating system, so one instruction sequence is not universal.
References: [1]
Kernel entry need not change the task
A system call, interrupt, or exception can enter the kernel and then return to the same task. Entry alone is therefore not a task context switch.
A timer can provide an opportunity for preemption, while an I/O wait can block the current task. Scheduling policy chooses what runs next; the switching mechanism implements that choice. Selection and state transfer have distinct responsibilities.
Costs extend beyond saved registers
Saving state takes time, and the next task can need to rebuild useful cached state. Address-space changes must also prevent reuse of an inappropriate translation, using mechanisms such as invalidation or address-space identifiers.
Shorter slices can improve initial response while increasing switch and cache-warming overhead. Evaluating the tradeoff requires workload and responsiveness goals, not simply minimizing the time between switches.