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

[Sven-Thorsten Dietrich <sven@thebigcorporation.com>]

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

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

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