Hi,
Pancakes wrote:
Brendan wrote:
It actually would be nice to get rid of IRQs and replace them with "hardware messages"; where a hardware message interrupts the currently running code (just like an IRQ would have), but consists of a "sender ID" (to identify the device that sent the IRQ) and some sort of device specific "status dword" (to identify the reason why the device is requesting attention - so the driver can figure out what it needs to do before/without touching the device's registers).
I like this idea, but it sounds like what basically already happens to some extent especially on ARM with full featured interrupt controllers. You actually have to check the interrupt controller to find out what device interrupted which is like it's "sender ID" then most devices have some type of MMIO register or MMIO registers to query the status.
Not having to do MMIO sounds like it could be an improvement (but see below), however usually you end up having to do more than just check the status so you might end up with other MMIO maybe taking up most of the time to service the device. I could see maybe a device such as a timer benefiting from this when all you needed was the interrupt yet the timer device has other functions.
The only real difference is the hardware message part, but I do not know if this would be any real improvement.
If you compare it to
MSI (where the device writes a configurable 32-bit value to a configurable address) you'll see the differences are very minor (as far as the device is concerned).
Pancakes wrote:
It is quite fast already just to raise a logic level to signal the interrupt controller we want to interrupt (which is FAST).
It's actually quite slow. For example (PIC chips) the CPU gets a signal from the interrupt controller, then CPU asks the interrupt controller which interrupt it is, then PIC tells CPU which interrupt, then software converts that into some sort of device identifier and notifies the device driver, then device driver asks the device what it wants. That's a whole pile of "back-and-forth" that does little more than add additional latency. For IO APICs it's not much better. For ARM (as far as I know) it's worse (because the CPU doesn't automatically ask the interrupt controller which interrupt it was so there's additional software overhead).
Pancakes wrote:
Considering a message of some sort would require more than one bit which would increase latency (if serial) for the device to go back to doing what it was doing or it would require more complicated circuits (if parallel) for which would increase heat and cost. You might actually find devices implement a single line to a dedicated chip that ends up doing all the sending of the hardware message and all you gained was more cost and little performance benefit if any.
For MSI, it's already 32 bits of data being sent by the device. That's plenty (e.g. maybe a 16-bit device ID and a 16-bit status).
Mostly, I'd want to improve IRQ latencies (by removing historical baggage) and reduce the hassle for hardware (by removing historical baggage), while making nothing worse (as it's so similar to what hardware is already doing anyway).
Cheers,
Brendan