zephyriot / zephyr-issues

0 stars 0 forks source link

Interrupt latency too large #1279

Open nashif opened 7 years ago

nashif commented 7 years ago

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)

nashif commented 7 years ago

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.

nashif commented 7 years ago

by Chuck Jordan:

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

nashif commented 7 years ago

by Mark Linkmeyer:

Fixing incorrect priority