What must survive a task switch

A thread's continuation includes an instruction location, stack state, register values, and the kernel bookkeeping that identifies its execution context. The exact division between an entry frame, a kernel stack, and explicitly saved switch state depends on architecture and the path into the scheduler. Do not imagine that one portable function blindly copies every register on every switch. Some values have already been saved by an interrupt or system-call entry sequence; other state is preserved according to architecture-specific conventions. Correctness means the resumed task observes its promised machine state, rather than prescribing one universal implementation of that promise.

The stack deserves special attention because suspended kernel calls may retain local variables and return addresses. Suppose a thread waits for a socket to become readable. Its execution has entered the kernel, determined that progress requires an external event, and blocked. Another task can now use the processor. When the socket event wakes the first thread, it becomes runnable; it does not necessarily resume immediately. Eventually the scheduler restores the continuation that lets its waiting operation recheck conditions and proceed. A wakeup therefore changes eligibility, while dispatch actually transfers execution. Confusing these events makes latency traces difficult to interpret.

A switch between threads in the same process can retain the same address-space mappings while changing stacks and thread-specific state. Switching between different address spaces may require installing different translation context. Translation caches complicate the picture: address-space identifiers can allow entries to coexist, while invalidations remain necessary when mappings change. It is incorrect to claim that every context switch always flushes every cache. Ordinary data caches usually contain reusable contents tagged by physical location, but the incoming workload may displace the outgoing workload's useful data. A resumed task can therefore pay indirect locality costs even when the switch path itself was short.

Floating-point and vector extensions add another layer. Their architectural state can be large, and enabled features differ across CPUs and operating-system configurations. Linux's x86 documentation discusses extended state and dynamically enabled features such as AMX; this is a concrete reason to record hardware and kernel configuration alongside measurements. Separately, entering the kernel may change page-table context for isolation even when the same thread returns immediately. That security transition is not proof that another task ran. Keep three questions separate: did privilege change, did address-space translation context change, and did the identity of the running task change?

Define the measured boundary before reporting a cost. A ping-pong benchmark between two threads includes synchronization, scheduler decisions, handoff, and possibly cache-line transfer. Dividing total time by the number of handoffs yields a useful benchmark-specific average, not an architecture-independent constant. A production request may instead experience long runnable delay before any actual switch occurs. Record elapsed time, task CPU time, scheduling events, affinity, and competing load where possible. Compare repeated distributions under the same conditions. If a new configuration reduces handoff time but lengthens queueing, the request can still become slower despite a technically faster switching path.

A first-order capacity budget can treat the measured direct cost per switch as constant over a narrowly defined experiment. This lets you ask whether switching consumes a negligible or material fraction of one CPU-second. It cannot predict cache recovery, simultaneous multithreading interference, or long-tail dispatch delay. In the lab, compare two separate fixed-rate capacity assumptions: arrival 2 with service 3, then arrival 2 with service 1. Before each run, press Reset, re-set both desired rates, predict the direction of change from four work units, then press Play or Step. Editing a control pauses but retains elapsed time, so it does not enact an overhead change along the previous trajectory. Each fresh run changes backlog with its own fixed arrival-minus-service rate. It has no tasks, registers, run queues, or context-switch events; use it to inspect capacity sensitivity, then return to scheduler traces to test the real mechanism.