mjhjmtu

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?

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_RT patch 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.

Preemptive kernel only means that there is no Big Kernel Lock.

Linux had preemptive multi-tasking (i.e. user code was preemptible) since its first moment (as far I know, the very-very first Linux 0.0.1 uploaded by Linus to the funet ftp server was already preemptive multitask). If you executed, for example, multiple compression or compilation processes, they were executed parallel from the first moment.

Contrary the - at the time - widely used Win31. On Win31, if a task got the CPU from the "kernel", by default it was its responsibility to determine when to give control back to the OS (or to other tasks). If a process had no special support for this feature (which required additional programming work), then while executing it, all other tasks were suspended. Even most basic apps integrated into the Win31 worked so.

Preemptive multitasking means, that the tasks have no way to allocate the CPU as they want. Instead, if their time slot expires, the kernel gets the CPU away from them. Thus, in preemptive operating systems, a badly written or badly functioning process can't freeze the OS, or avoid other processes from running. Linux was always preemptive for user space processes.

The Big Kernel Lock means that in some cases, inside kernel space, still there could be some locks, preventing other processes from running the protected code. For example, you could not mount multiple filesystems concurrently - if you gave multiple mount commands, they were still executed consecutively, because mounting things required to allocate the Big Kernel Lock.

Making the kernel preemptive had required to eliminate this big kernel lock, i.e. making the mount and any other tasks to be able to run concurrently. It was a big job.

Historically, this was made really urgent by the increasing support of SMP (multi-CPU support). In the first time, there were really multiple-CPU mainboards. Later multiple CPUs ("cores") were integrated into a single chip, today the really multi-CPU mainboards are already rare (they are typically in costly server systems). Also the really single-core systems (where there is only a single cpu, with a single core) are rare.

Thus, the answer to your question isn't that "what was the reason of non-preemptivity", because it was always preemptive. The real question is, what made the preemptive kernel execution really necessary. The answer is for that: the increasing ratio of the many-CPU, many-core systems.

This isn't a technical answer but a historical answer to the specific question posed by the OP: "What was the reason of the non-preemptivity of older Linux kernels?"

(I assume, as explained by @peterh in his answer and comments, that by "non-preemptivity" the OP is referring to either or both of the fact that only one user process could be inside the kernel (in an API) at a time and/or the Big Kernel Lock.)

Linus Torvalds was interested in learning how operating systems worked, and the way he learned was to write one. His model, and base, and initial development environment was Minix, an existing OS for educational purposes (i.e., not a production OS) which was not free (as in open source, at that time - it wasn't free as in beer, either).

So he wrote a kernel with no preemption (the Big Kernel Lock mentioned in other answers) because that's the way you do it if you want to get your new OS up and running quickly for educational purposes: it's much much much much simpler that way. A kernel to support concurrent multiprogramming of user programs and devices is hard enough - it's extremely difficult to make the kernel itself concurrent.

If he had known then how popular/useful/important Linux would become ... he would have probably done it the same way. (IMO only, I have no idea what he actually thinks.) Because you've gotta walk before you can run.

And it stayed that way for a good long while because a) there was a lot of other work to be done on making Linux what it is today (or even what it was then) and b) to change it would be a major difficult undertaking (as explained in other answers).