Awesome question—multicore systems turn interrupt handling from a straightforward single-core task into a coordinated dance across multiple processing units. Let’s break down how each interrupt category works in this context, with practical details you’d encounter in real-world operating systems:

Hardware Interrupts #

The biggest shift here is interrupt affinity—the ability to bind specific hardware interrupts to individual cores. Here’s how it plays out:

• Administrators or the OS can explicitly pin interrupts (like those from a network card or GPU) to a dedicated core. This avoids the performance hit of interrupts bouncing between cores, which causes cache invalidation and context-switch overhead.
• For unbound hardware interrupts, the OS uses load-balancing logic (like round-robin or idle-core preference) to distribute them via the APIC (Advanced Programmable Interrupt Controller). Unlike single-core PICs, multicore systems use an I/O APIC to route interrupt requests to one or more local APICs (one per core).
• Some hardware supports multi-vector interrupts, allowing a single device to send different interrupts to different cores (e.g., a network card splitting receive and transmit interrupts across two cores for better throughput).

Program Interrupts (Exceptions) #

These are triggered by CPU instruction errors (divide-by-zero, page faults, illegal instructions) and are inherently tied to the core executing the faulty code:

• A program interrupt can only be handled by the core that encountered it, since it’s deeply linked to the core’s current execution context (registers, stack, process state). For example, a page fault requires the core to modify the process’s page table and handle memory swapping—something no other core can do without taking over the full context.
• Multicore-specific caveat: When handling shared resources (like global page caches), the core must use synchronization primitives (spinlocks, mutexes) to avoid race conditions with other cores accessing the same data.

CPU Timer Interrupts #

Timer interrupts power process scheduling, timekeeping, and periodic tasks. In multicore setups:

• Each core has its own local timer (managed by its local APIC) that triggers independently. This lets each core handle its own time-slice scheduling—when the timer fires, the core’s scheduler picks the next process to run without relying on a single global timer.
• Global clock synchronization is critical. The OS periodically calibrates all core timers against a hardware clock (like the TSC, Time Stamp Counter) to prevent drift. Some systems use a "master core" to broadcast sync signals to all other cores.
• Timer interrupts also trigger global load balancing: A core’s scheduler might check overall system load during a timer tick and initiate process migration to underutilized cores.

Input/Output (I/O) Interrupts #

These signal the completion of an I/O operation (e.g., a disk read finishing) and overlap with hardware interrupts, but have multicore-specific optimizations:

• Interrupt coalescing: High-throughput devices (like NVMe SSDs) aggregate multiple I/O completion events into a single interrupt to reduce "interrupt storms" that would bog down cores.
• Core pinning for I/O processes: If a process initiated an I/O request on a specific core, the OS routes the completion interrupt to that same core. When the process is awakened, it runs on the core with its data already in cache, cutting down on context-switch and cache-miss overhead.
• Threaded interrupt handling: Most modern OSes split I/O interrupt processing into two phases: a fast, minimal first phase (acknowledge the interrupt, save hardware state) runs in interrupt context, while the heavy lifting (notifying the process, updating buffers) runs in a kernel thread that can be scheduled on any available core, preventing interrupt latency.

内容的提问来源于stack exchange，提问作者godfreddigod