On Thu, 2009-10-22 at 15:25 -0500, Clark Williams wrote: > Got some good feedback on the first round, but missed CC'ing rostedt, > since he isn't on linux-rt-users, so here's the revised text with > the edits from dvhart and sven applied: > > ---------------------8< snip 8<---------------------------------- > > Q. How does Real-Time Linux (aka the PREEMPT_RT patch) improve > "latency"? > > A. The Linux RT patch modifies the behavior of the most common > kernel-level locking primitive (the spinlock) and kernel interrupt > handling logic, 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 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"). These two properties mean > that interrupts may 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" > (http://en.wikipedia.org/wiki/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 kernel locking, interrupts have been threaded, > meaning that instead of handling interrupts in a special "interrupt > context", each interrupt number has a dedicated thread for running its s/interrupt number/interrupt line/ > service routines. Interrupts go to a common handler and that handler > schedules the appropriate thread to service the interrupt. This means > that interrupt service order may be prioritized by assigning appropriate > realtime priorities to the interrupt threads. 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. > > ---------------------8< snip 8<---------------------------------- > > Kinda big for an elevator pitch, but hey, I'm sure the marketing and > sales guys will paraphrase it into "It makes things go Real Fast!" :) Doesn't it? <kidding> -- Steve -- 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
