0

I read that an interrupt in Linux (this was about a Raspberry Pi) can take a "long time" to process or let's say "start doing what the programmer wants". Is that true and how bad is it? Is there a big difference between Python and C?

In hardware ("bare metal") it should only take a few cycles to jump the start of an interrupt handler procedure/function, correct? If I interpret this correctly, on the new Raspberry Pi 4 it should take less than 10 nanoseconds. I'm mostly interested in the Raspberry Pis and other ARM-based hardware, but data for other platforms would also be nice. I assume an ARM bare metal is a lot faster than an AVR (Arduinos)..?

Edit: Clarified question somewhat. Thanks @dirkt!

Bonus question: In pure assembly without an OS I can probably expect the time from physical event to my interrupt handler procedure running to be pretty much the same every time. How much does it vary in Linux? (Because the kernel might have other things to do, etc)

Edit 2: Found this blogpost, which pits a Raspberry Pi Zero against an Arduino Uno. The author also tried a kernel module which seems to be almost as fast as a bare metal AVR (but it's a 16 MHz AVR vs a 1GHz ARM!), which, I wonder, is how close to bare metal on the ARM? Pretty close to my original question, but without bare metal ARM.

  • 1
    Could you provide a reference where it says "an interrupt can take a long time to trigger"? Linux is not a real-time OS, so it can take a non-bounded amount of time before an interrupt is completely processed. In some cases, that may be unacceptable for applications where you need a respone to certain interrupt in a given amount of time. But triggering an interrupt just depends on the hardware, and can't be sped up. "Bare metal" is not concerned with processing the interrupt at all... – dirkt Jul 14 at 12:44
  • @dirkt Sorry, I didn't put much thought into the word "trigger". Your comment makes me think it's the wrong term. Please disregard. I'm looking at this from the point of view of a software author: How long does it take for my code to start running (usng Linux vs writing the bare minimum minimum without any OS)? The worst case is also an important aspect, in "bare metal" I assume it's pretty much fixed. In Linux it will be more random? – Higemaru Jul 14 at 13:45
  • 1
    As a said: Linux is no RTOS, so there's no bound. On "bare metal" there's no OS, so you have to write the complete OS yourself, and whatever you write will determine how long it takes. The thing is that you'll possibly be interrupting other routine handlers that process other interrupts ... – dirkt Jul 14 at 17:13
  • 1
    Depending on the ARM core, an interrupt will take much more than just a few clock cycles to change execution mode, switch registers and clear the pipeline, for example. An RTOS will add more overhead to store the whole register set, Linux will add even more, as you already read. That's the reason why a lot of SOCs with ARM Cortex-A cores have an (asymmetric) Cortex-M co-processor to handle real-time events. Even a slow-clocked Cortex-M core can outperform a GHz core with a tuned Linux in terms of real-time response. – Philippos Jul 17 at 14:57
  • 1
    It's something done by the processor. ARM cores have different operation modes like user, supervisor, interrupt and others, each with a separate register set. Switching those in hardware is faster than in software. Anyhow, not all registers are switched, so any OS not aware of what is done during interrupt needs to take the time to save and restore them. For small assembly IRQ handlers you can use the dedicated FIQ (fast interrupt) registers only and avoid any register saving. Anyhow, you have the overhead of pipeline clearing, which is different for different ARM cores. – Philippos Jul 19 at 6:05
1

I just read the article. With respect to kernel module. I agree it may be power saving. I was also thinking it may be because of other interrupts.

Kernel module should be as fast as bare metal, if conditions are the same: same power state, same other interrupts.

Beware kernel module can crash your system, so keep it small and simple.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.