proposed FAQ entry for rt.wiki.kernel.org

[Clark Williams <williams@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

Today, for the Nth time, I was asked by a potential customer "How does
the RT patch improve latency?". I looked at rt.wiki.kernel.org,
hoping (vainly) that someone had written up an elevator-pitch for the
RT patch, but it was not to be. So I wrote up something that I hope
made sense and sent it off. 

Since then I did a little bit of tweaking and expansion and thought I'd
send it to the RT users list to see if we can agree on an answer, then
put that in the RT FAQ. 

So, please read and critique the following:

Q. How does the Linux RT kernel improve "latency"?

A. The Linux RT patch modifies the behavior of spinlocks and
interrupt handling, to increase the number of points where a
preemption or reschedule may occur. This reduces the amount of time a
high priority task must wait to be scheduled when it becomes ready to
run, reducing event service time (or "latency"). 

Most spinlocks in the kernel are converted to a construct called an
rtmutex, which has the property of *not* disabling interrupts while
the lock is held and will sleep rather than spin. This means that
interrupts will occur while rtmutexes are held and interrupt handling
is a potential preemption point; on return from handling an interrupt,
a scheduler check is made as to whether a higher priority thread needs
to run.

The rtmutex locking construct also has a property known as "priority
inheritance", which is a mechanism for avoiding a deadlock situation
known as "priority inversion". In order to prevent a low priority
thread that is holding a lock from preventing a higher priority thread
from running, the low priority thread temporarily inherits the
priority of the highest priority thread that is requesting the lock,
which allows the low-priority thread to run until it completes its
critical section and releases the lock. 

In addition to changing spinlocks, interrupts have been threaded,
meaning that instead of handling interrupts in a special "interrupt
context", each IRQ has a dedicated thread for running its
ISRs. Interrupts go to a common handler and the handler schedules the
appropriate thread to handle the interrupt. This means that sleeping
spinlocks (rtmutexes) have a context to return to and that interrupt
handling can be prioritized by assigning appropriate realtime
priorities to the interrupt threads. 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]