Re: [patch] IRQ threads

[hui]

On Wed, Jul 28, 2004 at 08:27:22AM +0200, Ingo Molnar wrote:
> this is an incorrect change, just grep for in_interrupt() in
> linux/drivers/ ...
> 
> I agree with the concept of using multiple threads for interrupts - i'll
> add that to the voluntary-preempt patch too. This is an essential
> feature to prioritize interrupts.

That way I picture the problem permits those threads to migration across
CPUs and therefore kill interrupt performance from cache thrashing. Do
you have a solution for that ? I like the way you're doing it now with
irqd() in that it's CPU-local, but as you know it's not priority sensitive.
 
> what do you think about making the i8259A's interrupt priorities
> configurable? (a'la rtirq patch) Does it make any sense, given how early
> we mask the source irq and ack the interrupt controller [hence giving
> all other interrupts a fair chance to arrive ASAP]?
> 
> Bernhard Kuhn's rtirq patch is for IO-APIC/APICs, but i think the
> latency issues could be equally well fixed by not keeping the local APIC
> un-ACK-ed during level triggered irqs, but doing the mask & ack thing.
> This will be slightly slower but should make them both redirectable and
> more symmetric and fair.

I think it's pretty complementary to what's going on, but it's also driven
by application demand, how it could possibly hook into the scheduler or
something else like that. There isn't a clear precedence for how to use
something like this potentially. LynxOS doesn't have priorities above
interrupt priorities, that mask interrupts somehow, but are folks that need
that kind of stuff and could certainly be added in a relatively trivial
manner.

My answer would be something like yes it's needed, but not now.

bill

-
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/