proposed FAQ entry for rt.wiki.kernel.org (v3)

[Clark Williams <williams@redhat.com>]

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

Due to the hue and cry over my inexcusable abuse of OS terminology,
here is a rework with the priority inversion section.  :)

----------------------8< snip 8<------------------------------

Q. How does Real-Time Linux (aka the PREEMPT_RT patch) improve
"latency"?

A. The Linux RT patch modifies the behavior of the most common
kernel-level locking primitive (the spinlock) and kernel interrupt
handling logic, 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 or
preventing task switching while the lock is held. It also has the
property of sleeping on contention rather than spinning (hence the
sometimes heard term "sleeping spinlocks"). These two properties mean
that interrupts may 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 condition known as
"priority inversion", where a high-priority thread is blocked from
executing by lower priority threads holding a shared lock.  In order
to prevent this condition, the low priority thread holding the lock
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. For
more information on priority inversion see:  

     http://en.wikipedia.org/wiki/Priority_inversion

In addition to changing kernel locking, interrupts have been threaded,
meaning that instead of handling interrupts in a special "interrupt
context", each interrupt number has a dedicated thread for running its
service routines. Interrupts go to a common handler and that handler
schedules the appropriate thread to service the interrupt. This means
that interrupt service order may be prioritized by assigning appropriate
realtime priorities to the interrupt threads.  Further, using realtime
priorities, user-level threads may be prioritized *above* certain
device level activity, allowing critical application tasks to take
precedence over device activity deemed less important.

----------------------8< snip 8<------------------------------



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