(Updated) Preemptible Kernel

Available at (about 29K):

http://tech9.net/rml/linux/patch-rml-2.4.10-pre4-preempt-kernel-1
http://tech9.net/rml/linux/patch-rml-2.4.9-ac9-preempt-kernel-1

for kernel 2.4.10-pre4 and 2.4.9-ac9, respectively.

Changes since previous post:
* update for new kernels
* fix newline/space format buglet

Changes since original patch:
* fix compile bug -- CONFIG_HAVE_DEC_LOCK is set as needed, now.

This patch allows a new config setting, CONFIG_PREEMPT (set in `Processor Type and Features') that enables a fully preemptible kernel. Preemption is controled via SMP lock points. Control of execution is yielded to higher processes even if the currently running process is in kernel space.

This should increase response and decrease latency, and is a highly recommended patch for real-time, audio, and embedded systems. However, it is recommended for anyone. I use it on my everyday workstation.

An interesting new article on a preemptible kernel in linux is available at:

http://www.linuxdevices.com/articles/AT5152980814.html

Robert M. Love
rml at ufl.edu
rml at tech9.net

This sounds interesting, but am I correct in assuming that this only allows preemption during code that is called from user space? For instance, it would be bad to preempt an ISR or BH, right? Actually... what happens if say, the kernel called from user space is holding a lock, and gets preempted?
Is there a mechanism to disable preemption while holding locks or at other
resources that need to be freed before another task is run?

By the way, are there any other 'modes of execution' for lack of a better word, besides IRS, B, and.... 'called from user space', also for lack of a better word. Forgive me, I'm not that familiar with the Linux kernel yet.

--> Phill Susi

The SMP locking mechanisms (spinlocks, readlocks, writelocks) are used to prevent preemption for reentrancy or data validity reasons (this is the same reason we do this for SMP). So, there is no worry about holding locks and whatnot.

We also don't allow preemption during interrupt handling, bottom halves, or during execution of the scheduler itself. So, you are correct again, no preemption during ISRs or BHs.

At all other times, preemption is allowed. It occurs when another task comes due for execution -- now, even if in kernel space, we will yield execution to the new process. Please give the patch a try, enable preemption, and see what you think.

Some other changes were made, too. Certain conditions were prevented (ie, dont return to user with a pending soft interrupt). A preemption counter is maintained, and the locks now modify it. A new TASK_PREEMPTING flag was created.

To answer your question, besides system calls (ie, `on behalf of a process') you have ISRs, BHs, wait-queued routines (a growing number of these), and other kernel threads (keventd, ksoftirqd, kswapd, etc) which are typically timer/queued events anyhow.

Robert M. Love
rml at ufl.edu
rml at tech9.net

The thread will eventually get rescheduled and release the lock.

IIRC spinlocks inhibit scheduling, the simplest way to handle that.

--
Daniel

with the preemption config set, there is a compile failure with the ieee1394 drivers. thank you to Patrick Chase and the others who reported this.

note: drivers are going to need to explicity include linux/sched.h if they use (certain) spinlock primitives and want to compile with CONFIG_PREEMPT set. its cleaner anyhow.

this patch is against 2.4.9-ac10 but should be fine for 2.4.10-pre5...

diff -urN linux-2.4.9-ac10/drivers/ieee1394/ linux/drivers/ieee1394/csr.c
@@ -10,6 +10,7 @@
  */
 
 #include <linux/string.h>
+#include <linux/sched.h>
 
 #include "ieee1394_types.h"
 #include "hosts.h"

Robert M. Love
rml at ufl.edu
rml at tech9.net