Understanding Linux Kernel Preemption

While configuring a Linux kernel, we can set some parameters that effect the system behavior. You can work with different priorities, scheduling classes and preemption models. It is very important to understand and choose the right parameters.

In this post I will cover the different preemption models and how does each one effect the user and kernel behaviour

If you configure the kernel (using make menuconfig) , you can find, usually in kernel features sub menu the option – Preemption model:


To understand each option lets take an example:

  • We have 2 threads – one with high real time priority(50) and the other with low RT priority(30)
  • The high priority thread went to sleep for 3 seconds
  • The low priority threads uses the CPU for user space calculations
  • After 3 seconds the high priority thread will wake up

This case is easy and reasonable but what happens if the low priority thread call a kernel code while the high priority is sleeping? It is depends on the above configuration

No Forced Preemption

The context switch is done only when we return from the kernel. Lets take an example :

  • We have 2 threads – one with high real time priority(50) and the other with low RT priority(30)
  • The high priority thread went to sleep for 3 seconds
  • The low priority threads calls a kernel code that last for 5 seconds
  • After 5 seconds the low priority thread returns from the kernel
  • The high priority thread will wake up (2 seconds late)

Lets see the code:

Kernel code – simple character device driver:

The read is delaying for 5 seconds (delay is a busy wait loop) and returns some data

The User space code:

  • The high priority goes to sleep for 3 seconds.
  • The low priority thread is sleeping for one second and then calls the kernel
  • The high priority is wake after 6 seconds:


Preemptible Kernel

In this configuration the context switch is done on time also in the kernel, means if we run the above test we will see the high priority thread waking up after 3 seconds:

It means that in this options the system will perform more context switches per second but it is more “real time”. On embedded systems with soft real time requirements it is a best practice to use this option but in a server system that we are usually work asynchronously the first option is better – less context switches – more cpu time

The output:


Voluntary Kernel Preemption

In this configuration the system is working like “no forced preemption” but if the kernel developer is writing a complex code it is responsible to check from time to time if a re scheduling is needed. He can do that with might_resched() function

So in this example, if we want to add this “check point” we will change the code:

If we comment out the line might_resched() it will be delayed for 7 seconds total, adding a cond_resched call will check and perform the context switch if other hi priority threads is awake. It will be called after 5 seconds (1 second before the call and 4 seconds in the kernel)



Full Real Time Preemption

If you apply the RT patch , You get an Hard realtime kernel. This means any code can block other , if you run an interrupt service routine code and something more urgent need to be handled it will block the ISR code. The patch changes the following:

  • Converting hardware Interrupts to threads with RT priority 50
  • Converting SoftIRQs to threads with RT 49 priority
  • Converting all spinlocks to mutexes
  • Configuring and using Hi resolution timers
  • some more minor features


After applying the patch you can see 2 more options in the menu:

The option “Preemptible Kernel (Basic RT)” is for debugging (see documentation)

To make all the above changes you need to select the last option – Fully Preemptible Kernel.

Now if you create a thread with RT priority bigger than 50 – it will block interrupts

Note that in this configuration the system has more tasks and performs more context switches per second. i.e. the CPU is spending more time switching tasks but we can hit any deadline required (1ms or more)



1 thought on “Understanding Linux Kernel Preemption

  1. nice post…

Leave a Reply

Your email address will not be published. Required fields are marked *