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. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
