On Sep 24, 2008, at 5:17 AM, Benjamin Herrenschmidt wrote:
On Wed, 2008-09-24 at 04:58 -0500, Milton Miller wrote:
The per-interrupt mask and unmask calls have to go through RTAS, a
single-threaded global context, which in addition to increasing
path length will really limit scalability. The interrupt controller
poll and reject facilities are accessed through hypervisor calls
which are comparable to a fast syscall, and parallel to all cpus.
Note also that the XICS code thus assumes, iirc, as does the cell IIC
code, that eoi is called on the -same- cpu that fetched the interrupt
initially. That assumption can be broken with IRQ threads no ?
There may be some implicit assumption in that we expect the cpu
priority to be returned to normal by the EOI, but there is nothing in
the hardware that requires the EOI to come from the same cpu as
accepted the interrupt for processing, with the exception of the IPI
which is per-cpu (and the only interrupt that is per-cpu).
It would probably mean adding the concept of the current cpu priority
vs interrupts and making sure we write it to hardware at irq_exit()
time when deferring the actual irq handlers.
The MPIC hardware, on the other hand, maintains a queue of pending
interrupts (It has been about a decade but the number 4-5 comes to
mind), and the hardware must receive the EOI on the cpu that took it.
I am guessing that the handling described (take level irq, mask it, eoi
it, dispatch the thread, then unmask it after processing) is a result
to work within those limitations. Do you know the cell IIC to know if
its mpic or xics in this regard?
The other unknown is the (very few) platforms that present as xics but
are really firmware on mpic. If they do a full virtual layer and don't
take shortcuts but do eoi/mask like described here they should work,
but I would not be surprised that does not hold true :-(.
milton
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
