ARC: Interrupt latency too large

[zephyrbot]

Reported by Chuck Jordan:

I've observed a slow-down in interrupt handling.

For SOC EM9D, on 8/23/2016, the latency benchmark showed
72 tcs = 3600 nsec
for the time to switch from ISR back to interrupt task.
But today, after changes were made related to unified kernel,
I see:
108 tcs = 5400 nsec
That is a 1.8usec increase PER interrupt. Too much.
I think this is due to the C-function overhead that was added in the Fast Interrupt handling (and RIRQ).

This is impacting SPI devices like an OLED display -- resulting in confused commands and lost of control of the display.

Further, I see that for EM7D, the slower fast interrupt case because only 1 register bank is available, the driver for the OLED display completely malfunctions AND
the Latency Benchmark results in a memerr exception.

(Imported from Jira ZEP-1402)

[zephyrbot]

by Chuck Jordan:

Comparing Nanokernel Latency benchmark for EM7D (30Mhz) with EM11D(20Mhz), I see that EM11D is slower for most of the 5 tests, except for test
3 - Measure time from ISR to executing a different fibre (rescheduled)
EM7D has a whopping 404 cycles
EM11D has only 247 cycles
EM7D does clock faster, but this is still 13.466usec here.
SPI interrupts can trigger another task to run, so it would take this path, and perhaps this path is just a tad too slow.
There is a lot of register restoring happening here in EM7D since all scratch registers were saved on the stack. EM11D has a second register bank -- so less cycles to restore.

[zephyrbot]

by Chuck Jordan:

ZEP-1412 opened to address the issue where FIRQ or RIRQ are not used by this benchmark. It is really measuring exception handling -- TRAP.

[zephyrbot]

by Mark Linkmeyer:

Fixing incorrect priority

[nashif]

@AdithyaBaglody can you please take a look and see if this is still valid and if we can do something about it?

[AdithyaBaglody]

@nashif I am getting 4500ns as the interrupt latency when I measure through tests/benchmarks/timing_info.
I don't really know how much is expected. The term large is quite ambiguous.

[nashif]

closing