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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:22 EST