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

[Clark Williams <williams@redhat.com>]

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

Got some good feedback on the first round, but missed CC'ing rostedt,
since he isn't on linux-rt-users, so here's the revised text with
the edits from dvhart and sven applied:

---------------------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 deadlock situation
known as "priority inversion"
(http://en.wikipedia.org/wiki/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 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<----------------------------------

Kinda big for an elevator pitch, but hey, I'm sure the marketing and
sales guys will paraphrase it into "It makes things go Real Fast!" :)

Clark




	

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