Re: proposed FAQ entry for rt.wiki.kernel.org

[Darren Hart <dvhltc@us.ibm.com>]

Clark Williams wrote:
> 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. 

I have "elevator pitch" on my todo list as well.  Good timing.

> 
> 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"?

"Linux RT" ... pretty close to RTLinux, which of course we can't use, so 
maybe use "Real-Time Linux" or "The PREEMPT_RT patch".

> 
> 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". 

A reference might be a good idea. The medium priority tasks not 
interested in the contended resource is a key aspect of 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 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. 

I think I'd focus a bit more on interrupt threads having configurable 
priorities.

I'm not sure the bit about "spinlocks have a context to return to" makes 
sense in an elevator-type pitch, might be too low level, and detract 
from the high-level message?


-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team