DRV-310 · Device Drivers

Interrupts & Threaded IRQs

Interrupt handling from the hardware edge to the bottom half, and how to keep hard IRQ context short.

Practitioner 3 days in person6 half-days online Max 14 in person

Who this course is for

Driver engineers who need interrupt handling that stays correct under load — short top halves, well-chosen bottom halves, and storms survived rather than debugged in production.

Prerequisites

DRV-110 device-model knowledgeC and kernel module build experienceKRN-230 (kernel locking) helpful but not required

Course outline

Day 1 — From pin to handler

  • Interrupt controllers, irq domains and the mapping chain
  • The interrupts property in DT and platform_get_irq
  • request_irq/free_irq and the IRQF flags
  • Top-half constraints: no sleeping, no user access, a hard time budget
  • Acking the device: the handler's first obligation

Day 2 — Deferring the work

  • Softirqs: what they are and why you will not add one
  • Tasklets and their deprecation path
  • Workqueues: ordering, concurrency and WQ flags
  • Threaded IRQs with request_threaded_irq: handler vs thread_fn
  • IRQF_ONESHOT and the shared-interrupt dev_id contract

Day 3 — Interrupts in the real world

  • Spurious interrupts and why they happen
  • IRQ storms: kernel detection, mitigation and fixing the real cause
  • Threaded IRQs under PREEMPT_RT and what changes there
  • IRQ affinity, smp_affinity and steering away from hot CPUs
  • Measuring handler cost with /proc/interrupts and the irqsoff tracer

Hands-on labs

Labs follow the academy model — 35% principles, 20% guided investigation, 45% engineering studio. Every claim you make in a lab is backed by a trace, a counter or a measurement you captured yourself. How we teach

  1. Lab: Wire a GPIO interrupt source from DT through platform_get_irq to a minimal top-half handler; count events in /proc/interrupts
  2. Lab: Move work from the top half to a workqueue, then to a threaded IRQ; measure latency and throughput for each shape
  3. Lab: Share an interrupt line between two devices, implement the dev_id check correctly and survive a spurious-IRQ flood
  4. Lab: Create an interrupt storm, watch the kernel's storm detection fire, then fix the handler to actually ack the device
  5. Lab: Compare your threaded IRQ's behaviour with and without PREEMPT_RT and capture the difference with the irqsoff tracer

Capstone project

Build the complete interrupt path for a lab device: DT mapping, a minimal top half that acks and defers, and a threaded bottom half doing the real work — then stress it with storm injection, shared-line contention and affinity steering, delivering latency distributions and a handler audit showing every top-half rule is honoured.

What you leave with

  • A correct request_threaded_irq implementation you can defend line by line
  • A decision method for top half vs workqueue vs threaded IRQ
  • Storm and spurious-IRQ survival techniques proven in lab
  • PREEMPT_RT awareness for interrupt-driven drivers
  • Measurement habits: /proc/interrupts and irqsoff evidence for every claim

How it runs

Every course follows the same model: 35% principles, 20% guided investigation, 45% engineering studio. You leave with working code, raw measurements and an evidence-based report — not a certificate of attendance. Read the methodology or see a full sample lesson.

Material is adapted to your kernel version, hardware and workload before a private delivery. For public cohorts, the environment is provided and configured.

Questions

Who is this course for?

Driver engineers who need interrupt handling that stays correct under load — short top halves, well-chosen bottom halves, and storms survived rather than debugged in production. It sits at practitioner level within the Device Drivers track.

What do I need to know already?

Specific prerequisites for this course: DRV-110 device-model knowledge; C and kernel module build experience; KRN-230 (kernel locking) helpful but not required. We confirm levels before the cohort starts and adapt if a group is stronger or weaker than expected.

Can this run privately for my team?

Yes. Any course runs on-site at your offices anywhere, or live online for a distributed team, with labs adapted to your hardware and codebase.

What is the difference between in-person and online?

In person is 3 full days with hardware on your desk, capped at 14. Online is 6 half-day sessions across about two weeks so you can keep working, capped at 20, with remote lab access.

Do you invoice companies?

Yes. Purchase orders are accepted and invoicing is available in USD, EUR, GBP, SAR and CAD.

Upcoming dates

DatesWhereSeatsEarly birdRegular
18 Oct – 20 Oct 20263 full days RiyadhIn person · KAFD Conference Centre 8 of 14 —SAR 7,880
25 Oct – 27 Oct 20263 full days Kuwait CityIn person · Al Hamra Tower 3 of 14 —KWD 650
1 Nov – 3 Nov 20263 full days MuscatIn person · Knowledge Oasis Muscat 8 of 14 —OMR 810
1 Nov – 8 Nov 20266 half-days Gulf bandLive online · 09:00–13:00 GMT+3 16 of 20 —US$1,500
2 Nov – 4 Nov 20263 full days OttawaIn person · Kanata North Tech Park 3 of 14 —CAD 2,860
9 Nov – 11 Nov 20263 full days TorontoIn person · MaRS Discovery District 8 of 14 CAD 2,570until 10 OctCAD 2,860
9 Nov – 16 Nov 20266 half-days Europe bandLive online · 09:00–13:00 CET 5 of 20 US$1,350until 10 OctUS$1,500
16 Nov – 18 Nov 20263 full days LondonIn person · Shoreditch Works 3 of 14 GBP 1,480until 17 OctGBP 1,640
16 Nov – 23 Nov 20266 half-days Americas bandLive online · 13:00–17:00 ET 10 of 20 US$1,350until 17 OctUS$1,500
23 Nov – 25 Nov 20263 full days BerlinIn person · Factory Görlitzer Park 8 of 14 EUR 1,740until 24 OctEUR 1,930

Dates shown for the next few months. If nothing fits, tell us where and when — cohorts are added on demand, and private delivery can be scheduled any week.

More in Device Drivers