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. 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"? 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". 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.
Attachment:
signature.asc
Description: PGP signature
