RE: [patch] voluntary-preempt-2.6.8-rc2-L2, preemptable hardirqs

From: Saksena, Manas
Date: Tue Jul 27 2004 - 22:27:48 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/