kernel preemption
When a program is running in user mode, the scheduler can interrupt it at almost any moment to give the CPU to a more urgent task. But for a long time, code running inside the kernel was exempt: once a thread entered the kernel (say, in the middle of a long file operation), it kept the CPU until it chose to give it up, even if something far more urgent woke up. Kernel preemption removes that exemption — it lets the kernel interrupt a task that is currently executing kernel code, so a higher-priority task does not have to wait for the slow one to finish in the kernel. Think of a checkout where, in the old days, once the cashier started ringing up a huge cart no one could cut in; with preemption, a flagged urgent customer can be served between any two items.
Concretely, a preemptible kernel allows a reschedule to happen at safe points while kernel code runs, not only when control returns to user space. When a higher-priority task becomes runnable, the kernel can save the current task's kernel-mode state and switch to the urgent one immediately. But preemption must be suppressed in delicate regions: while a spinlock is held or per-CPU data is being manipulated, preemption is temporarily disabled so the task is not switched out mid-critical-section (which could deadlock or corrupt data). The kernel keeps a per-task preemption counter; when it is zero and a reschedule is pending, preemption is allowed.
It matters most for responsiveness and real-time behavior: without kernel preemption, a high-priority task can suffer long, unpredictable latency just because some unrelated task is deep in a kernel call. That is why preemptible and fully preemptible (PREEMPT_RT) configurations exist for low-latency and real-time work. The honest trade-off is that preemption adds overhead and complexity — more places where a switch can occur means more careful locking — so a server tuned purely for throughput might prefer less preemption, while an audio or robotics system needs more.
Task A is deep inside a kernel file-system operation when high-priority Task B (an audio thread that must deliver the next sound buffer) wakes up. On a non-preemptible kernel, B waits until A leaves the kernel — possibly long enough to cause an audible glitch. On a preemptible kernel, the kernel switches to B at the next safe point inside A's kernel code, and the audio plays smoothly.
Kernel preemption lets an urgent task break into a task that is still running in the kernel.
Preemption is not the same as interrupts: an interrupt always runs its handler, but it does not by itself switch tasks; preemption is the scheduler deciding to switch the running task. Crucially, while a spinlock is held the kernel disables preemption — so sleeping or blocking while holding a spinlock is forbidden and a common cause of hangs.