Introduction

At any moment, dozens of hardware devices may need the CPU’s attention—network packets arriving, keystrokes pressed, disk operations completing, timers firing. The CPU cannot continuously poll every device (wasteful) nor can devices wait indefinitely (data would be lost). The interrupt mechanism bridges this gap: devices assert a signal that causes the CPU to suspend current work and handle the event immediately.

Interrupts are the nervous system of computing—electrical impulses that demand immediate attention. Without them, operating systems would be blind to the physical world. Understanding interrupt handling is essential for driver development, system performance tuning, and debugging real-time or latency-sensitive applications.

Polling represents the alternative model—software repeatedly checking device status registers to see if work needs doing. This section explores both models, their trade-offs, and the hybrid approaches modern systems use.

When to Use / When Not to Use

When Hardware Interrupts Are Appropriate

• Sparse, unpredictable events: Network packets arriving, user input, hardware faults
• Latency-critical operations: Real-time systems where sub-millisecond response matters
• Low-power designs: CPU can sleep until hardware signals need for service
• High-bandwidth devices with flow control: Disks, high-speed network cards that can buffer temporarily

When Polling Is Appropriate

• Dense, predictable events: High-frequency timers, status monitoring
• Latency-jitter-tolerant designs: When consistent polling interval is acceptable
• Interrupt storm prevention: Devices that naturally generate very high interrupt rates
• Virtualized environments: Hypervisors may emulate interrupt delivery; polling vCPUs can be more efficient
• Modern NVMe drives: Internal queue depths and interrupt coalescing make polling viable

Hybrid Approaches (The Common Case)

Modern systems rarely use pure polling or pure interrupts. They combine:

• Interrupt coalescing: Accumulate multiple events before interrupting
• Deferred processing: Fast ISR handles minimal work; rest runs in thread context
• Polled phases: During intensive work, temporarily switch to polling for cache efficiency

Architecture or Flow Diagram

The following diagram illustrates the complete interrupt handling flow from hardware assertion to driver completion:

sequenceDiagram
    participant HW as Hardware Device
    participant CPU
    participant IDT as Interrupt Descriptor Table
    participant ISR as Interrupt Service Routine<br/>(Top Half)
    participant BH as Bottom Half Handler<br/>(Tasklet/Workqueue)
    participant DRV as Device Driver

    HW->>CPU: Assert IRQ line
    CPU->>CPU: Finish current instruction
    CPU->>IDT: Lookup interrupt vector
    IDT->>ISR: Jump to handler
    ISR->>HW: Acknowledge interrupt
    ISR->>ISR: Read status registers
    ISR->>BH: Schedule bottom half
    ISR-->>CPU: Return from interrupt

    Note over CPU: Now running other work
    BH->>DRV: Process I/O completions
    DRV->>DRV: Handle data, wake waiters

The critical insight is the split between the top half (ISR, runs with interrupts disabled) and the bottom half (runs later, in process context). This split minimizes interrupt latency while allowing lengthy processing.

Core Concepts

Hardware Interrupts

Hardware interrupts are electrical signals from devices to the CPU requesting attention. The interrupt request (IRQ) line the device uses determines which handler runs.

Types of interrupts:

• Maskable interrupts (IRQ): Can be ignored by setting the IF flag in EFLAGS/RFLAGS
• Non-maskable interrupts (NMI): Cannot be ignored—used for critical events like hardware failures
• Message-signaled interrupts (MSI/MSI-X): Device writes to special memory address instead of using physical IRQ line; avoids interrupt pin limitations

Interrupt lifecycle:

// 1. Driver registers handler during initialization
static int my_driver_probe(struct pci_dev *pdev)
{
    int ret;

    // Register interrupt handler
    ret = request_threaded_irq(
        pdev->irq,                    // IRQ line
        my_driver_isr,               // Top half (atomic)
        my_driver_thread,            // Bottom half (threaded, can sleep)
        IRQF_SHARED,                  // Share IRQ with other devices
        "my_driver",                 // Name for /proc/interrupts
        my_dev);                     // Passed to handler

    return ret;
}

// 2. Interrupt fires, CPU vectors to ISR
static irqreturn_t my_driver_isr(int irq, void *dev_id)
{
    struct my_device *dev = dev_id;
    u32 status = readl(dev->regs + STATUS_REG);

    if (!(status & IRQ_PENDING))
        return IRQ_NONE;  // Not our interrupt

    // Acknowledge—prevention of spurious interrupts
    writel(status, dev->regs + STATUS_REG);

    // Store any needed state for bottom half
    dev->interrupt_status = status;

    return IRQ_WAKE_THREAD;  // Schedule threaded handler
}

// 3. Threaded handler runs in process context
static irqreturn_t my_driver_thread(int irq, void *dev_id)
{
    struct my_device *dev = dev_id;
    u32 status = dev->interrupt_status;

    if (status & PACKET_AVAILABLE)
        process_packets(dev);

    if (status & BUFFER_DONE)
        complete_transfer(dev);

    return IRQ_HANDLED;
}

IRQ Handling in Linux

The Linux kernel maintains an IRQ descriptor table. When an interrupt fires:

1. Kernel disables interrupts on that CPU (mask)
2. Looks up handler in irq_desc[]
3. Calls handler chain (multiple drivers can share one IRQ line)
4. Acknowledges interrupt to interrupt controller (PIC/APIC)
5. Re-enables interrupts (unmask)

The APIC (Advanced PIC) handles interrupt routing in modern multi-core systems, enabling per-core interrupt affinity—IRQs can be directed to specific CPUs for cache efficiency.

Interrupt Bottom Halves

The top half (ISR) must run quickly and cannot sleep. Bottom halves handle the heavy processing.

Tasklets — Lightweight, scheduled per-CPU, cannot be preempted:

// Tasklet structure embedded in device struct
struct my_device {
    // ... other fields ...
    struct tasklet_struct tlet;
    u32 pending_work;
};

// Initialize tasklet
void my_device_init(struct my_device *dev)
{
    tasklet_init(&dev->tlet, my_device_tasklet, (unsigned long)dev);
}

// Tasklet function (runs in interrupt context, but can schedule)
void my_device_tasklet(unsigned long data)
{
    struct my_device *dev = (struct my_device *)data;
    u32 work = xchg(&dev->pending_work, 0);  // Atomically grab and clear

    if (work & PACKET_WORK)
        process_packets(dev);
    if (work & TIMER_WORK)
        handle_timer(dev);
}

// In ISR: schedule tasklet instead of direct processing
static irqreturn_t my_isr(int irq, void *dev_id)
{
    struct my_device *dev = dev_id;
    u32 status = readl(dev->regs + STATUS_REG);

    dev->pending_work |= status;
    tasklet_schedule(&dev->tlet);  // Schedule bottom half

    return IRQ_HANDLED;
}

Workqueues — Run in kernel thread context, can sleep, can be delayed:

// Work structure for deferred processing
struct delayed_work {
    struct work_struct work;
    struct timer_list timer;
};

// Initialize work
INIT_WORK(&dev->work, process_workqueue);
INIT_DELAYED_WORK(&dev->delayed_work, process_delayed);

// Schedule immediate work
schedule_work(&dev->work);

// Schedule delayed work (5 jiffies)
schedule_delayed_work(&dev->delayed_work, 5);

// In driver cleanup
flush_work(&dev->work);
cancel_delayed_work_sync(&dev->delayed_work);

Threaded IRQs — Simpler model: handler runs as a kernel thread:

// request_threaded_irq combines ISR + thread in one call
// ISR is minimal (runs atomic), thread handles rest
ret = request_threaded_irq(
    irq,
    isr_routine,     // Optional primary handler (can return IRQ_WAKE_THREAD)
    threadRoutine,    // Threaded handler (can sleep)
    flags,
    name,
    dev_id);

Polling Model

Polling uses explicit software checking instead of hardware signals:

// Simple polling loop (inefficient—don't do this!)
while (device_has_work()) {
    handle_device_event();
}

// Better: timer-driven polling with adjustable rate
static void poll_timer_callback(struct timer_list *t)
{
    struct my_device *dev = from_timer(dev, t, poll_timer);

    // Check and handle any pending work
    u32 status = readl(dev->regs + STATUS_REG);
    if (status)
        process_status(dev);

    // Reschedule if device still needs servicing
    if (device_needs_poll(dev))
        mod_timer(&dev->poll_timer, jiffies + POLL_INTERVAL);
}

// Initialize polling
timer_setup(&dev->poll_timer, poll_timer_callback, 0);
add_timer(&dev->poll_timer);

Comparison: Interrupts vs Polling

Aspect	Interrupts	Polling
CPU overhead (idle device)	Zero—CPU sleeps	Constant—CPU checks repeatedly
Response latency	Immediate—hardware signals	Bounded by poll interval
Scalability	Pin-limited (MSI helps)	No hardware limit
Complexity	More complex (handling race conditions)	Simpler state machine
Event density	Degrades at high rates	Handles high rates naturally
Power consumption	Lower when idle	Higher when idle

Production Failure Scenarios

Scenario 1: Interrupt Storm from Misbehaving Hardware

What happened: A faulty network card generated spurious interrupts at 50,000+ per second after receiving certain packet patterns. Each interrupt forced CPU context switches, consuming 40% of one core and causing massive latency spikes for legitimate operations.

Detection: cat /proc/interrupts showed interrupt count incrementing in thousands per second for that IRQ line. top showed softirq CPU time dominating.

Mitigation:

// Limit interrupt rate by returning IRQ_NONE for spurious events
static irqreturn_t net_driver_isr(int irq, void *dev_id)
{
    struct net_device *ndev = dev_id;
    u32 status = readl(ndev->regs + IRQ_STATUS);

    // If no real interrupt source, pretend we didn't see it
    if (!(status & (TX_DONE | RX_PENDING | LINK_CHANGE)))
        return IRQ_NONE;  // Spurious—don't reschedule

    // Handle real sources, acknowledge, schedule NAPI if needed
    // ...
    return IRQ_HANDLED;
}

Also configure interrupt coalescing in hardware to reduce interrupt frequency.

Scenario 2: Deadlock from Blocking in ISR

What happened: A driver’s ISR called copy_to_user() which can fault and may sleep on some architectures. On an ARM platform, this caused a deadlock—the ISR had interrupts disabled and the page fault required an interrupt to handle memory management, but interrupts were masked.

Detection: System hang with “scheduling while atomic” kernel panic.

Mitigation:

// BAD: copy_to_user can sleep
static irqreturn_t bad_isr(int irq, void *dev_id)
{
    char buf[256];
    // DON'T do this—copy_to_user can fault
    copy_to_user(user_buf, kernel_buf, sizeof(buf));
    return IRQ_HANDLED;
}

// GOOD: Use put_user in atomic context (designed for ISR)
static irqreturn_t good_isr(int irq, void *dev_id)
{
    // put_user is atomic-safe, no sleeping
    put_user(kernel_value, user_ptr);
    return IRQ_HANDLED;
}

// For larger data, defer to bottom half
static irqreturn_t isr(int irq, void *dev_id)
{
    // Store minimal info, schedule work
    dev->pending_data_len = readl(dev->regs + LEN_REG);
    tasklet_schedule(&dev->tlet);
    return IRQ_HANDLED;
}

static void tlet_handler(unsigned long data)
{
    struct my_device *dev = (void *)data;
    // Now in process context—copy_to_user is safe
    copy_to_user(dev->user_buf, dev->kernel_buf, dev->pending_data_len);
}

Scenario 3: Race Between ISR and Driver Removal

What happened: Driver was being unloaded while interrupts were still in flight. The ISR dereferenced memory that had been freed during driver removal, causing a use-after-free panic.

Detection: Kernel panic in ISR context with corrupted data structures.

Mitigation:

static int my_driver_remove(struct pci_dev *pdev)
{
    struct my_device *dev = pci_get_drvdata(pdev);

    // Synchronize with any pending interrupts
    // 1. Prevent new interrupts
    disable_irq(pdev->irq);

    // 2. Wait for any in-flight ISRs to complete
    synchronize_irq(pdev->irq);

    // 3. Now safe to free resources
    tasklet_kill(&dev->tlet);
    devm_free_irq(&pdev->dev, pdev->irq, dev);
    pci_set_drvdata(pdev, NULL);

    return 0;
}

Also use reference counting (kref_get/kref_put) to ensure device data isn’t freed while any code (ISR or otherwise) might access it.

Trade-off Table

Mechanism	Latency	CPU Overhead (idle)	Throughput ceiling	Complexity
Bare interrupts	Lowest (immediate)	Zero	Limited by IRQ rate	Medium
Interrupt + tasklet	Low + deferred processing	Minimal when idle	High (batched)	Medium
Threaded IRQ	Low + full kernel features	Context switch cost	High	Low
NAPI (poll mode)	Higher (polling interval)	Zero when idle	Very high	High
Pure polling	Bounded by interval	Constant 100%	Limited by poll freq	Low

Implementation Snippets

Complete Interrupt-Driven Driver Framework

#include <linux/module.h>
#include <linux/interrupt.h>
#include <linux/workqueue.h>
#include <linux/timer.h>

#define SHARED_IRQ
#define POLL_INTERVAL (HZ / 10)  // 100ms

struct my_device {
    void __iomem *regs;
    unsigned int irq;
    struct tasklet_struct tlet;
    struct work_struct work;
    struct timer_list poll_timer;
    u32 interrupt_count;
    bool use_polling;  // Fallback when interrupts fail
};

static irqreturn_t my_driver_isr(int irq, void *dev_id)
{
    struct my_device *dev = dev_id;
    u32 status;

    /* Read status - clears interrupt latches in hardware */
    status = readl(dev->regs + INT_STATUS);
    if (!status)
        return IRQ_NONE;

    /* Atomically store status for bottom half */
    dev->interrupt_count++;

    /* For this device, bottom half is tasklet */
    tasklet_schedule(&dev->tlet);

    return IRQ_HANDLED;
}

static void my_tlet_handler(unsigned long data)
{
    struct my_device *dev = (struct my_device *)data;
    u32 status = readl(dev->regs + INT_STATUS);

    /* Process packet arrivals */
    if (status & PKT_AVAILABLE) {
        struct sk_buff *skb = dev_alloc_skb(2048);
        if (skb) {
            /* Transfer data - DMA or MMIO */
            read_memcpy_from_io(skb_put(skb, 2048),
                               dev->regs + RX_BUFFER, 2048);
            netif_rx(skb);
        }
    }
}

static void my_work_handler(struct work_struct *work)
{
    /* For longer operations that can't sleep in tasklet */
    struct my_device *dev = container_of(work, struct my_device, work);

    /* Process configuration changes, etc. */
    msleep(10);  // Safe here
}

/* Polling fallback for environments with broken interrupts */
static void my_poll_timer(struct timer_list *t)
{
    struct my_device *dev = from_timer(dev, t, poll_timer);
    u32 status = readl(dev->regs + INT_STATUS);

    if (status & PKT_AVAILABLE)
        my_tlet_handler((unsigned long)dev);

    if (dev->use_polling)
        mod_timer(&dev->poll_timer, jiffies + POLL_INTERVAL);
}

static int my_driver_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
    struct my_device *dev;
    int ret;

    dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
    if (!dev)
        return -ENOMEM;

    pci_set_drvdata(pdev, dev);

    /* Map hardware registers */
    dev->regs = pcim_iomap(pdev, 0, 0);
    if (!dev->regs)
        return -ENOMEM;

    /* Request IRQ - threaded variant for sleeping-capable handler */
    ret = request_threaded_irq(pdev->irq, NULL, my_threaded_isr,
                               IRQF_SHARED, KBUILD_MODNAME, dev);
    if (ret) {
        dev_warn(&pdev->dev, "IRQ %u unavailable, using polling\n", pdev->irq);
        dev->use_polling = true;
        timer_setup(&dev->poll_timer, my_poll_timer, 0);
        mod_timer(&dev->poll_timer, jiffies + POLL_INTERVAL);
    } else {
        dev->irq = pdev->irq;
    }

    /* Initialize tasklet and work */
    tasklet_init(&dev->tlet, my_tlet_handler, (unsigned long)dev);
    INIT_WORK(&dev->work, my_work_handler);

    return 0;
}

static void my_driver_remove(struct pci_dev *pdev)
{
    struct my_device *dev = pci_get_drvdata(pdev);

    if (dev->use_polling) {
        del_timer_sync(&dev->poll_timer);
    } else {
        free_irq(pdev->irq, dev);
    }

    tasklet_kill(&dev->tlet);
    cancel_work_sync(&dev->work);

    pci_set_drvdata(pdev, NULL);
}

static struct pci_device_id my_driver_id[] = {
    { PCI_DEVICE(0x1234, 0x5678) },
    { }
};
MODULE_DEVICE_TABLE(pci, my_driver_id);

static struct pci_driver my_driver = {
    .name = KBUILD_MODNAME,
    .id_table = my_driver_id,
    .probe = my_driver_probe,
    .remove = my_driver_remove,
};
module_pci_driver(my_driver);

Python Simulation of Interrupt vs Polling

#!/usr/bin/env python3
"""
Simulates interrupt vs polling paradigms for I/O handling.
"""
import time
import threading
from dataclasses import dataclass
from typing import Callable
import random


@dataclass
class Device:
    """Simulated hardware device with interrupt capability."""
    name: str
    interrupt_callback: Callable[[], None]
    event_interval_ms: float  # How often device generates events

    def __post_init__(self):
        self._running = False
        self._thread = None

    def start(self):
        """Simulate device generating interrupts."""
        self._running = True
        def event_loop():
            while self._running:
                time.sleep(random.uniform(0, self.event_interval_ms * 2) / 1000)
                if self._running and random.random() < 0.7:  # 70% event rate
                    self.interrupt_callback()
        self._thread = threading.Thread(target=event_loop, daemon=True)
        self._thread.start()

    def stop(self):
        self._running = False
        if self._thread:
            self._thread.join(timeout=1.0)


class InterruptDrivenHandler:
    """Handle events immediately via callback."""
    def __init__(self):
        self.events_handled = 0
        self.last_event_time = None

    def handle_interrupt(self):
        self.events_handled += 1
        self.last_event_time = time.time()
        # Simulate minimal ISR work
        self._process_event()

    def _process_event(self):
        pass  # In real ISR, this would be minimal


class PollingHandler:
    """Handle events by periodic checking."""
    def __init__(self, device: Device, poll_interval_ms: float = 100):
        self.device = device
        self.poll_interval = poll_interval_ms / 1000
        self.events_handled = 0
        self.last_poll_time = None
        self._running = False
        self._thread = None
        self._pending = False  # Simulated device register

    def start(self):
        self._running = True
        def poll_loop():
            while self._running:
                self.last_poll_time = time.time()
                # Read device "registers" (check for pending events)
                self._check_device()
                time.sleep(self.poll_interval)
        self._thread = threading.Thread(target=poll_loop, daemon=True)
        self._thread.start()

    def _check_device(self):
        # Simulate reading status register
        if random.random() < 0.7:  # 70% chance of event pending
            self.events_handled += 1

    def stop(self):
        self._running = False
        if self._thread:
            self._thread.join(timeout=1.0)


if __name__ == "__main__":
    print("=== Interrupt vs Polling Simulation ===\n")

    # Interrupt-driven
    handler_int = InterruptDrivenHandler()
    device = Device("UART0", handler_int.handle_interrupt, event_interval_ms=10)
    device.start()
    time.sleep(1.0)
    device.stop()

    print(f"Interrupt-driven: {handler_int.events_handled} events handled")
    print(f"  Average latency: ~{(1.0/handler_int.events_handled)*10:.2f}ms (estimated)")

    # Polling
    handler_poll = PollingHandler(device, poll_interval_ms=50)
    device2 = Device("UART1", lambda: None, event_interval_ms=10)
    device2.start()
    handler_poll.start()
    time.sleep(1.0)
    handler_poll.stop()
    device2.stop()

    print(f"\nPolling (50ms interval): {handler_poll.events_handled} events handled")
    print(f"  Average latency: ~{handler_poll.poll_interval * 1000 / 2:.1f}ms (half poll interval)")

Observability Checklist

Linux Interrupt Metrics

# View all IRQ statistics
cat /proc/interrupts

# Per-CPU interrupt counts
cat /proc/softirqs  # Software interrupt (softirq) handling

# Check interrupt affinity
cat /proc/irq/32/smp_affinity  # Which CPU handles IRQ 32

# Set interrupt affinity (move NIC IRQ to CPU 0)
echo 1 > /proc/irq/42/smp_affinity

# View interrupt distribution with perf
perf stat -e 'irq:irq_handler_entry' -a sleep 1

Key Metrics to Monitor

Metric	Healthy Range	Alert Threshold	Indicates
/proc/interrupts (per-IRQ delta)	Baseline + small variance	Sudden 10x increase	Interrupt storm
softirq time in top	< 5% CPU	> 30% CPU	ISR deferred work overload
irq_entry perf events	< 10,000/s	> 100,000/s	Excessive interrupts
nmi count delta	Stable	Increasing	Hardware issues (memory errors)

Common Pitfalls / Anti-Patterns

Interrupt Security Concerns

1. Interrupt Timing Attacks: Observing interrupt timing can leak information. Deterministic scheduling of bottom halves can expose sensitive computation patterns. Consider using hrtimer for high-resolution timing rather than relying on interrupt patterns.

2. IRQ Routing Attacks: In virtualized environments, a malicious VM could manipulate interrupt routing to cause denial of service against other VMs sharing the same physical CPU. Use IOMMU interrupt remapping and verify APIC configuration.

3. MSI-X Vulnerabilities: Message-signaled interrupts write to memory addresses. If those addresses aren’t properly restricted, a device could potentially signal interrupts that access arbitrary memory. Modern systems use ATS (Address Translation Services) to validate DMA requests.

4. Interrupt Descriptor Table (IDT) Attacks: Malware can hook IDT entries to intercept interrupts. Use kexec to reload a known-good kernel or verify IDT integrity with cat /proc/kallsyms | grep idt_table.

Common Pitfalls / Anti-patterns

Anti-pattern	Why It’s Bad	Correct Approach
Long-running ISR	Blocks all interrupts, causes latency spikes	Defer to tasklet/workqueue
Blocking in ISR	Scheduling while atomic = panic	Use non-blocking primitives
Not acknowledging interrupts	Spurious interrupts repeat forever	Always acknowledge in hardware
No IRQ sharing cleanup	Leak resources on driver removal	Use free_irq with proper synchronization
Assuming single CPU	Race conditions on SMP	Use proper locking/synchronization
Disabling interrupts globally	Excessive latency for other devices	Use per-IRQ masking instead
Not handling interrupt storms	Denial of service from device	Implement coalescing/irq throttling

Quick Recap Checklist

• Hardware interrupts allow devices to demand CPU attention asynchronously
• ISRs run with interrupts disabled—keep them fast and never block
• Bottom halves (tasklets, workqueues, threaded IRQs) defer lengthy processing
• Tasklets run in interrupt context but can schedule; workqueues run in process context
• Polling is the alternative—better for high-density events, worse for power/latency
• Hybrid NAPI model combines interrupts (for idle) with polling (for busy)
• Always acknowledge hardware interrupts to prevent spurious repeats
• Use synchronize_irq() before freeing IRQ-related resources
• Monitor /proc/interrupts and softirqs to detect interrupt storms
• Interrupt storms usually indicate hardware or driver bugs, not feature

Interview Questions

Further Reading

• Linux Kernel Documentation: IRQ subsystem — Official documentation covering interrupt management, handler registration, and IRQ descriptors
• Linux Kernel Documentation: IRQ threading — Guide to threaded IRQs and IRQ affinity
• Intel Software Developer Manual, Chapter 6 — Complete reference on interrupt architecture, IDT, and APIC
• ARM Interrupt Architecture — ARM’s interrupt handling documentation for embedded systems
• NAPI: New API for Network Drivers — Linux networking documentation on hybrid interrupt-polling
• USENIX ‘02: Efficient IRQ Balancing — Research on SMP interrupt distribution optimization

Conclusion

Interrupts and polling represent two fundamental models for device-CPU communication, with modern systems blending both into hybrid approaches. Hardware interrupts provide immediate response for sparse, unpredictable events; polling handles dense, predictable workloads without interrupt overhead. The top-half/bottom-half split in Linux interrupt handling reflects this: ISRs run atomic and fast, while deferred handlers do lengthy work in process context.

Understanding interrupt handling prepares you for deeper OS topics: the interaction between interrupt context and scheduler, the security implications of IRQ routing in virtualized environments, and the evolution toward message-signaled interrupts that avoid physical pin limitations. These fundamentals also appear in ARM and RISC-V interrupt controllers, embedded real-time operating systems, and hypervisor virtual interrupt delivery.

Looking forward, the lines between interrupt and polling continue blurring as hardware supports interrupt coalescing, modern NVMe drives benefit from pure polling during intensive periods, and software-defined interrupt controllers enable flexible IRQ routing for power and performance optimization.