5
votes

Here is some description quoted from Wiki

The Linux kernel provides preemptive scheduling under certain conditions. Until kernel version 2.4, only processes were preemptive, i.e. in addition to time quantum expiration, an execution of current process in user mode would be interrupted if higher dynamic priority processes entered TASK_RUNNING state. Towards Linux 2.6, an ability to interrupt a task executing kernel code was added, although with that not all sections of the kernel code can be preempted.

Then it also says this,

Preemption improves latency, increases responsiveness, and makes Linux more suitable for desktop and real-time applications. Older versions of the kernel had a so-called big kernel lock for synchronization across the entire kernel. This was finally removed by Arnd Bergmann in 2011

So does the above statement hold true for the current linux kernel that kernel preemption is conditional? e.g. if a process is trapped into kernel mode by making a system call, this process will not be under preemptive scheduling?

Where can I find some up-to-date introduction articles/books about linux scheduling in both user mode and kernel mode?

2

2 Answers

4
votes

Of course kernel preemption is conditional. You would not want the kernel to switch tasks while holding an exclusive lock or while writing to time-sensitive hardware registers in a device driver.

However, the Linux kernel does its best to minimize these conditions in order to make preemption happen as quickly as it can.

Note that this in-kernel preemption is only compiled into the kernel when the compile option CONFIG_PREEMPT is yes. There is also CONFIG_PREEMPT_VOLUNTARY which only does task switching when the kernel explicitly checks for it.

Kernel preemption comes with a cost. Rapidly switching tasks requires doing a lot of mostly wasted housekeeping work instead of actual work. This slows down the whole system and results in less work being done. That is why these compile options exist. A Linux kernel built for a database or web server should not use preemption at all. A kernel built for HPC is sometimes modified to only switch tasks once a second, or less.

That all changes for real-time tasks. These tasks rely on reacting quickly and within a reliable timeframe. The default Linux kernel is pretty good at this, but there is a patch set called the "-rt patches" that makes it really good. The patch set does all sorts of things like prioritize interrupt handlers and change kernel locks so that locks can be dropped and restarted later.

3
votes

CPU scheduling decisions may take place when a process:

1. Switches from running to waiting state (e.g. I/O request)
2. Switches from running to ready state (e.g. Interrupt)
3. Switches from waiting to ready (e.g. I/O completion)
4. Terminates

Scheduling under 1 and 4 are non-preemptive and all other scheduling is preemptive, have to deal with possibility that operations (system calls) may be incomplete.

Yes Linux provides preemptive scheduling under certain conditions unlike some Unix variants where kernel schedules until completion without preemption. In Linux 2.6, kernel was made preemptive a task running as long it is not holding a lock and safe to rescheduling.

Older versions of the kernel had a so-called big kernel lock for synchronization 
across the entire kernel.

refers to each user-level thread maps only to one kernel thread.