What's the cost of a context switch and why does it matter?

A context switch costs CPU cycles to save and restore the registers (about half the integer context by software, the rest by hardware auto-stacking), update the two stack pointers and TCBs, and run the scheduler's decision about which task is next, on the order of roughly a hundred cycles on a Cortex-M, more if the FPU context is involved. It matters because it happens on every preemption and every time slice, so it's pure overhead subtracted from useful work, and it's part of your real-time timing budget: worst-case response latency includes the switch time (plus, since the switch defers to PendSV after ISRs, any in-flight interrupt time). If you over-decompose the system into many tasks, or use a very short tick that time-slices aggressively, or have tasks that signal each other constantly, the accumulated switch overhead can become a significant fraction of CPU and erode determinism. So the design guidance is to make tasks coarse enough that switching is a small fraction of their work, prefer event-driven blocking over rapid time-slicing, and account for switch time when computing whether a task set is schedulable. It's small per switch but real in aggregate and in the worst-case latency calculation.