interrupt overhead on ARM architecture

interrupt overhead on ARM architecture

[Alessio Sangalli]

Hi there, I was wondering if somebody ever did some measurements of the
interrupt overhead, measured in clock cycles. Basically how much time it
takes to do the context switch and reach the ISR, and back. My target is
the ARM9...

Thanks
Alessio

Re: interrupt overhead on ARM architecture

[Iwo Mergler]

Alessio Sangalli wrote:
> Hi there, I was wondering if somebody ever did some measurements of the
> interrupt overhead, measured in clock cycles. Basically how much time it
> takes to do the context switch and reach the ISR, and back. My target is
> the ARM9...
> 
> Thanks
> Alessio
>
This depends very much on the system, both hardware and software.

The ARM9 processor can get from an active interrupt line to the
first instruction in the ISR in about 30 clock cycles.

However, it can take a multiple of that if the ISR and relevant
stacks are not in cache. On many systems this can cost you
a few hundred processor clocks, depending on what the software
did just before the interrupt.

At this point the OS ISR is running. It needs to find out which
hardware device triggered. The processor has only one interrupt
line (OK, two), but some systems have hundreds of interrupt sources.

Depending on the interrupt controller hardware, finding out which
interrupt fired, is a matter of reading one register in the best case.
Or reading several and searching for set bits in software in the
worst case. Again, a few tens of cycles, depending on the system
architecture.

Only then the OS ISR can actually call the driver's ISR, which
is probably what you are really interested in.

In other words, you can't even measure the latency on a particular
system and then assume it will stay anywhere near constant. Comparing
different systems with the same processor core is hopeless.


Kind regards,

Iwo

Re: interrupt overhead on ARM architecture

[Alessio Sangalli]

Iwo Mergler wrote:

> In other words, you can't even measure the latency on a particular
> system and then assume it will stay anywhere near constant. Comparing
> different systems with the same processor core is hopeless.

Everything makes perfect sense. For this reason, I am willing to do some
tests on my own platform. How would you suggest to proceed? I would need
an extremely accurate way to measure time to begin with and then:

- read that time reference
- generate an interrupt by placing some data in a device or so
- reading again that time reference as first thing in the ISR
- save the result

- do the above in various scenarios, with different drivers enabled, CPU
load, etc etc

bye
Alessio

Re: interrupt overhead on ARM architecture

[Benjamin Herrenschmidt]

On Tue, 2008-07-29 at 00:08 -0700, Alessio Sangalli wrote:
> Iwo Mergler wrote:
> 
> > In other words, you can't even measure the latency on a particular
> > system and then assume it will stay anywhere near constant. Comparing
> > different systems with the same processor core is hopeless.
> 
> Everything makes perfect sense. For this reason, I am willing to do some
> tests on my own platform. How would you suggest to proceed? I would need
> an extremely accurate way to measure time to begin with and then:
> 
> - read that time reference
> - generate an interrupt by placing some data in a device or so
> - reading again that time reference as first thing in the ISR
> - save the result
> 
> - do the above in various scenarios, with different drivers enabled, CPU
> load, etc etc

Do you have some device you can toy with such as an FPGA ? If not, you
can use also a pair of GPIOs hooked up to an oscillo.

Have one GPIO be an interrupt, and the interrupt handler for it toggle
the second GPIO.

Then, stick a push button to the first GPIO and wire it to your
oscilloscope's first input, and the second to the second input, set the
trigger on the first input, and here you go...

Ben.