What is the difference between a "Non-preemptive", "Preemptive" and "Selective Preemptive" Kernel?
Hope someone can shed some light into this.
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
On a preemptive kernel, a process running in kernel mode can be replaced by another process while in the middle of a kernel function.
This only applies to processes running in kernel mode, a CPU executing processes in user mode is considered "idle". If a user mode process wants to request a service from the kernel, he has to issue an exception which the kernel can handle.
As an example:
A executes an exception handler, Process
B gets awaken by an IRQ request, the kernel replaces process
B (a forced process switch). Process
A is left unfinished. The scheduler decides afterwards if process
A gets CPU time or not.
On a nonpreemptive kernel, process
A would just have used all the processor time until he is finished or voluntarily decides to allow other processes to interrupt him (a planned process switch).
Today's Linux based operating systems generally do not include a fully preemptive kernel, there are still critical functions which have to run without interruption. So I think you could call this a "selective preemptive kernel".
Apart from that, there are approaches to make the Linux kernel (nearly) fully preemptive.
the preemption is -> The ability of the operating system to preempt or stop a currently scheduled task in favour of a higher priority task. The scheduling may be one of, but not limited to, process or I/O scheduling etc.
Under Linux, user-space programs have always been preemptible : the kernel interrupts user-space programs to switch to other threads, using the regular clock tick. So, the kernel doesn't wait for user-space programs to explicitly release the processor (which is the case in cooperative multitasking). This means that an infinite loop in an user-space program cannot block the system.
However, until 2.6 kernels, the kernel itself was not preemtible : as soon as one thread has entered the kernel, it could not be preempted to execute an other thread. However, this absence of preemption in the kernel caused several problems with regard to latency and scalability. So, kernel preemption has been introduced in 2.6 kernels, and one can enable or disable it using the CONFIG_PREEMPT option. If CONFIG_PREEMPT is enabled, then kernel code can be preempted everywhere, except when the code has disabled local interrupts. An infinite loop in the code can no longer block the entire system. If CONFIG_PREEMPT is disabled, then the 2.4 behaviour is restored.
ReQuoted and formatted from: http://www.linuxquestions.org/questions/linux-general-1/pre-emptive-vs-non-pre-emptive-kernel-582437/
A preemptive kernel allows a process to be preempted while it is running in kernel mode. A nonpreemptive kernel does not allow a process running in kernel modeto be preempted; a kernel-mode process will run until it exits kernel mode, blocks, or voluntarily yields control of the CPU. Obviously, a nonpreemptive kernel is essentially free from race conditions on kernel data structures, as only one process is active in the kernel at a time. We cannot say the same about preemptive kernels, so they must be carefully designed to ensure that shared kernel data are free from race conditions. Preemptive kernels are especially difficult to design for SMP architectures, since in these environments it is possible for two kernel-mode processes to run simultaneously on different processors. A preemptive kernel is more suitable for real-time programming, as it will allow a real-time process to preempt a process currently running in the kernel. Furthermore, a preemptive kernel may be more responsive, since there is less risk that a kernel-mode process will run for an arbitrarily long period before relinquishing the processor to waiting processes. Of course, this effect can be minimized by designing kernel code that does not behave in this way. Later in this chapter, we explore how various operating systems manage preemption within the kernel.