Are interrupts really interruptions?

Perhaps not.

Devices generate interrupts to seek the processor's attention.

Controllers routes the interrupts to the appropriate CPU core.

Just like the iconic Charon of the Continental (PS. Don’t tell me you never watched John Wick!).

Ring ring, hello yes?

Mr. Processor, I have an urgent telegram for you from Mr. NC!”

That's the fundamentals.

Interrupts pause the current process flow;

Much like a tap on the shoulder when you're deep in thought.

It's easy to point fingers at the controller or the device.

But you know what?

Getting frustrated is pointless - it just wastes more jiffies.

Interrupts are crucial components that enhance system responsiveness.

As a Linux kernel developer, here are few point to etch in mind when dealing with interrupts and handlers:

• 𝐼𝑛𝑡𝑒𝑟𝑟𝑢𝑝𝑡 ℎ𝑎𝑛𝑑𝑙𝑒𝑟𝑠 𝑟𝑢𝑛 𝑤𝑖𝑡ℎ 𝑖𝑛𝑡𝑒𝑟𝑟𝑢𝑝𝑡𝑠 𝑑𝑖𝑠𝑎𝑏𝑙𝑒𝑑. They are like surgeons in the operating room - all other distractions are kept out to avoid compromising the procedure.

• 𝐼𝑛𝑡𝑒𝑟𝑟𝑢𝑝𝑡𝑒𝑑 𝐶𝑃𝑈 𝑐𝑜𝑟𝑒 𝑚𝑎𝑠𝑘𝑠 𝑖𝑛𝑡𝑒𝑟𝑟𝑢𝑝𝑡𝑠 like a librarian demanding silence in the study hall - no interrupt repeats for that core! Though other cores can still party on.

• 𝑆ℎ𝑎𝑟𝑒 𝑑𝑎𝑡𝑎 𝑐𝑎𝑟𝑒𝑓𝑢𝑙𝑙𝑦 𝑏𝑒𝑡𝑤𝑒𝑒𝑛 𝑐𝑜𝑛𝑡𝑒𝑥𝑡𝑠. No one likes race conditions except rats and reality show producers!

• 𝐻𝑎𝑛𝑑𝑙𝑒𝑟𝑠 𝑐𝑎𝑛𝑛𝑜𝑡 𝑏𝑙𝑜𝑐𝑘 - no Uber to user space, no schedule() tweets! Stay focused.

• 𝑂𝑓𝑓𝑙𝑜𝑎𝑑 𝑤𝑜𝑟𝑘 𝑤ℎ𝑒𝑛 𝑝𝑜𝑠𝑠𝑖𝑏𝑙𝑒. Deferred work should run in process context - tasklets, bottom halves, work queues . No texting in movie theaters!

• 𝑁𝑜 𝑠𝑙𝑒𝑒𝑝() 𝑜𝑛 𝑡ℎ𝑒 𝑗𝑜𝑏! Stay alert and ready to respond.

• 𝐷𝑜𝑛'𝑡 𝑜𝑣𝑒𝑟-𝑚𝑎𝑠𝑘 𝑖𝑛𝑡𝑒𝑟𝑟𝑢𝑝𝑡𝑠 everywhere. Share them across cores to improve responsiveness!

• 𝐾𝑒𝑒𝑝 𝑎𝑐𝑡𝑖𝑜𝑛𝑠 𝑒𝑠𝑠𝑒𝑛𝑡𝑖𝑎𝑙. Service the device fast then say "Peace!"

Mishandling interrupts risks latency lags, lost signals, and instability no one wants to debug.

No matter how disruptive their timing may seem, address interrupts with patience.

Mask the unavoidable.

Process the necessary.

Queue the rest.

Originally shared on LinkedIn