Why did the first Linux developers choose to implement a non-preemptive kernel? Is it to save synchronization?
As far as I know, Linux was developed in the early '90s, when PCs had a single processor. What advantage does a non-preemptive kernel give in such PCs? Why, however, the advantage is reduced by multi-core processors?
Best Answer
In the context of the Linux kernel, when people talk about pre-emption they often refer to the kernel’s ability to interrupt itself — essentially, switch tasks while running kernel code. Allowing this to happen is quite complex, which is probably the main reason it took a long time for the kernel to be made pre-emptible.
At first most kernel code couldn’t be interrupted anyway, since it was protected by the big kernel lock. That lock was progressively eliminated from more and more kernel code, allowing multiple simultaneous calls to the kernel in parallel (which became more important as SMP systems became more common). But that still didn’t make the kernel itself pre-emptible; that took more development still, culminating in the
PREEMPT_RTpatch set which was eventually merged in the mainline kernel (and was capable of pre-empting the BKL anyway). Nowadays the kernel can be configured to be more or less pre-emptible, depending on the throughput and latency characteristics you’re after; see the related kernel configuration for details.As you can see from the explanations in the kernel configuration, pre-emption affects throughput and latency, not concurrency. On single-CPU systems, pre-emption is still useful because it allows events to be processed with shorter reaction times; however, it also results in lower throughput (since the kernel spends time switching tasks). Pre-emption allows any given CPU, in a single or multiple CPU system, to switch to another task more rapidly. The limiting factor on multi-CPU systems isn’t pre-emption, it’s locks, big or otherwise: any time code takes a lock, it means that another CPU can’t start performing the same action.