Messages in this thread | | | Date | Wed, 28 Jul 2004 19:24:16 -0400 | Subject | Re: [patch] IRQ threads | From | Scott Wood <> |
| |
On Wed, Jul 28, 2004 at 08:27:22AM +0200, Ingo Molnar wrote: > > 4. This might be a good time to get around to moving the bulk of the > > arch/whatever/kernel/irq.c into generic code, as the code said was > > supposed to happen in 2.5. This patch is currently only for x86 > > (though we've run IRQ threads on many different platforms in the > > past). > > agreed. I punted this one for the time being as it's clearly separate > from the issue of latencies and it's deeply intrusive to 2.6.
The intrusiveness is somewhat mitigated by not having to convert all architectures at once, though; the generic code would only be included for those architectures that set the relevant CONFIG_. At that point, it basically is just moving code from one file to another (for x86), and doing minor tweaks for those architectures that are close to what x86 does.
> > 5. Is there any reason why an IRQ controller might want to have its > > end() called even if IRQ_DISABLED or IRQ_INPROGRESS is set? It'd be > > nice to merge those checks in with the > > IRQ_THREADPENDING/IRQ_THREADRUNNING checks. > > e.g. in the IO-APIC case if we ack the local APIC only in the end() > function then we must do that - an un-acked local APIC prevents other > IRQs from being delivered. We do this for level-triggered IO-APIC irqs.
Yes, but the IO-APIC code needs to be changed anyway to work properly with IRQ threads.
> 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]?
It could be useful for SA_NOTHREAD interrupts, but I don't think it buys much for threaded interrupts (as you'd have to wait until normal IRQs are enabled to schedule the handler thread anyway).
> 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 agree. How much slower would it be (is it worth an #ifdef for irq threads)? Hopefully PIC operations aren't as slow as they are on the 8259...
-Scott - 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/
| |