Messages in this thread | | | Subject | RE: [patch] voluntary-preempt-2.6.8-rc2-L2, preemptable hardirqs | Date | Tue, 27 Jul 2004 23:26:10 -0400 | From | "Saksena, Manas" <> |
| |
Lee Revell wrote: > On Tue, 2004-07-27 at 12:27, Ingo Molnar wrote: >> i've uploaded -L2: >> >> >> > http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2 >> -L2 >> >> the hardirq-redirection feature is activated via >> voluntary-preemption=3 (default). All irqs except the timer irq are >> redirected. (the timer irq needs to run from irq context - but it has >> constant latency and constant frequency so it's not an issue. Soft >> timers are executed from the timer softirq which is redirected and >> hence preemptable.) >> >> this means that with this patch applied the 2.6 UP kernel is quite >> close to being hard-RT capable (using controlled drivers and >> workloads). All unbound-latency asynchronous workloads have been >> unloaded into synchronous, schedulable process contexts - so nothing >> can delay a high-prio RT task. (assuming we caught all the latencies. >> Any remaining latency can be fixed with the existing methods.) >> > The obvious next feature to add would be to make certain IRQs > non-schedulable, like you would for an RT system. For an > audio system this would be just the soundcard interrupt (and timer as > stated above). Then, while it still might not be hard-RT, it would > blow away anything achievable on the other OS'es people do audio work > with.
Its really useful to have a thread per IRQ and to have an option to run a particular IRQ handler in hardirq context. Then a system designer or adminstrator can tune the priorities of different IRQ handler threads depending on the latency requirements of a particular system. Scott's patch posted earlier (see link below) implements this -- this has proven
handy in many scenarios including, but not restricted to, audio real-time performance.
http://marc.theaimsgroup.com/?l=linux-kernel&m=109096903816850&w=2
Manas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |