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

[Clark Williams <williams@redhat.com>]

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

On Thu, 22 Oct 2009 11:16:27 -0700
Darren Hart <dvhltc@us.ibm.com> wrote:

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

How's this:

Q. How does Real-Time Linux (aka the PREEMPT_RT patch) 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". 
> 
> 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

Yeah, I didn't want to get into a full-on discussion of priority
inversion, so a reference is a good idea.

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

Well, some of the people that have asked were actually looking for a
more technical description than was available in, ahem, Marketing
Literature. So I guess I was attempting to straddle that fence. I will
re-arrange that last sentence to put prioritization first or may be
split it into two sections. How about this:

This means that interrupt service order may be prioritized by
assigning appropriate realtime priorities to the interrupt threads. 

Yeah, I see what you mean about "context to return to". A bit too deep
for the 30-second description. 

Clark

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