Messages in this thread | | | Date | Tue, 29 Feb 2000 18:39:24 +0100 (MET) | From | Roman Zippel <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
Hi,
On Sun, 27 Feb 2000, Ingo Molnar wrote:
> yep. In 2.5 the IA32 irq.c will probably be moved into kernel/irq.c so > it's important to keep it 64-bit clean. Since there are 11 different > architectures in the main tree now (and 2-3 not yet integrated ones) this > can definitely not happen now, but will be very important to do in 2.5.
It would be great, if I could be notified when this is going to happen (or at least the architecture maintainers, Jes will surely forward it). I see some possible problems if you going to unify it too much and define some requirements, that might need some workarounds.
First, isn't the irq probing stuff ISA related? I don't know of any other insanity that would need this.
My second and main problem there is do_IRQ(). Is that really supposed to be architecture dependend? On a halfway sane interrupt architecure I optimize you this, so that there is almost nothing left, that couldn't be done in the assembler entry immediatly. Unfortunately my knowledge about the ia32 interrupt stuff isn't as good as I'd like to, anyway, I hope that most of the following ideas don't seem to come from a different world. :)
- I think the spinlock in there isn't really necessary, if real state changes are only happen from non-interrupt contexts. Everywhere else would be a "disable_irq(); spin_lock()" sequence sufficient. - I doubt that all the status stuff is really necessary, except for IRQ_INPROGRESS for SMP synchronisation. - IRQ_REPLAY: Do interrupt handler require a real interrupt context or isn't a faked context sufficient? - IRQ_WAITING: it's only used for int probing and could IMO be moved to a special interrupt handler. - IRQ_DISABLED: We could implement an optimistic scheme, where we replace the action field with a dummy action, that keeps the interrupt disabled. enable_irq()/disable_irq() would be very cheap then and we disable the interrupt only when the really interrupt happens (and most of the time not at all for short disable_irq()/enable_irq() sequences). - IRQ_PENDING: If I interpret the comment there correctly, the check is only necessary for faulty SMP hardware?
A related problem: IMO it's possible to do the soft irqs to do without turning on/off interrupts all the time, all we have to do is to make sure that only the last interrupt enters do_softirq() (local_irq_count could be used for that) and only at exit of do_softirq() we have to disable interrupts again to check for more pending soft irqs and to finally drop the interrupt context.
Partly I did stuff like this already, although for m68k port, but it made it possibly to install _very_ thin realtime layer (the current RTLinux stuff could also be much simpler), basically normal interrupts were only delayed into the soft irq part and only real time interrupts were executed immediatly. That allowed me to install a special serial interrupt handler that could handle the byte stream from the stupid 1-byte-fifo in the Amiga at 57600 bps and more. We have PPC Amigas with 200MHz and more that can't do that under Linux. :-(
Ok, I hope that gives some ideas what could be improved (I have more of them :-) ), maybe I can hack something together, that also works on ia32.
bye, Roman
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |