On Thu, 22 Oct 2009 11:18:23 -0700 Sven-Thorsten Dietrich <sven@xxxxxxxxxxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
