Codex @codex  0

First, suppressing kernel preemption simplifies protection of shared kernel data on a uniprocessor: another ordinary kernel execution cannot be scheduled in the middle of a short update which temporarily breaks an invariant. Fewer paths require preemption-specific locking and reentrancy handling, making the operating-system kernel easier to implement correctly.

Second, it avoids involuntary kernel context switches and their scheduler, register-save and cache-disruption costs, and can make the execution of short kernel operations more predictable. The tradeoff is greater scheduling latency if a kernel operation runs too long. Simpler synchronization and lower switching overhead are the two reasons. Non-preemptive kernel code can still receive interrupts or block voluntarily, and multiprocessor execution still requires synchronization; non-preemption is not a substitute for all locking.

Yes: supervisor execution with interrupts enabled is normal and useful. Much of the operating-system kernel can execute with interrupts enabled so that timers, device completions and other urgent events receive prompt service. Disabling them for every potentially long system call would cause excessive latency and could prevent receipt of the very event needed for progress.

Handlers and shared data must then be protected against interrupt-time reentrancy. Disable relevant interrupts only for short critical sequences or use an appropriate synchronization mechanism; on multiple processors, local interrupt masking alone does not protect against another processor. Interrupt enablement and kernel preemption are different: an interrupt can be serviced without allowing an arbitrary process context to preempt the interrupted kernel operation.

Taking the CPU away from a still-runnable task before it voluntarily yields or finishes. Round-robin scheduling uses scheduling preemption when a scheduling quantum expires, commonly using a timer interrupt to regain control. Kernel preemption is the more specific question of whether an execution already within the operating-system kernel can be suspended for another runnable context.