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

[Clark Williams <williams@redhat.com>]

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

On Thu, 22 Oct 2009 11:18:23 -0700
Sven-Thorsten Dietrich <sven@thebigcorporation.com> wrote:

> On Thu, 2009-10-22 at 12:08 -0500, Clark Williams wrote:
> > 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
> 
> simpler: "Kernel-level locking". Avoids "whats a spinlock?"

Yeah, I can go with that. Although, we might do it this way:

The Linux RT patch modifies the behavior of the most common
kernel-level locking primitive (the spinlock) and interrupt handling,
to increase the number of points where a preemption or reschedule may
occur.

> 
> > 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.
> 
> Technically, not all spinlocks disable irqs.
> 
> maybe "property of *not* preventing task switching or suppressing
> interrupt services on a particular CPU while..."
> 

Agreed, but the rtmutex *does* have the property of not disabling
interrupts, so it's a nop when replacing spinlocks that don't as well.
I do like calling out that the conversion explicitly enable task
switching though. How about this:

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


> >  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. 
> 
> Further, user-level processes may be prioritized above device-level
> services, allowing computational load and I/O load to be dynamically
> expedited, partitioned, or decoupled.

You used to work in marketing, didn't you :)

How about:

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.

Clark
 

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