Intel Preps Linux For Directed Package Thermal Interrupts

Intel Linux engineers are preparing the Linux kernel's Intel Thermal driver for supporting Directed Package Thermal Interrupts as a new feature of recent Intel CPUs. Rather than package-level thermal interrupts being broadcast to all CPU cores, newer Intel CPUs allow for just broadcasting them to one CPU core tasked with the package-wide events. This cuts down on resource contention and can avoid needlessly waking up possible idle CPU cores.

The Linux patches don't note which new Intel CPU cores support this directed package thermal interrupts functionality, but it was just added to the Intel Software Developer Manual last month, potentially indicating it's only coming with Nova Lake ~ Diamond Rapids but the cover letter notes "newer" Intel CPUs supporting it, so we'll see in practice which processors end up having this support.

The patch series explains of this new Intel Thermal feature: "Package-level thermal interrupts are currently broadcast to all CPUs in a package. Only one CPU is needed to service package-wide events. Moreover, broadcasting may create resource contention. An example of this are thermal interrupts posted for Hardware Feedback Interface updates: all CPUs in the package receive the interrupt and then race to grab a lock to update a data structure common to all CPUs. Idle CPUs were needlessly woken up. Newer Intel processors allow directing package-level thermal interrupts only to CPUs that explicitly request them. A CPU opts in by setting bit 25 in IA32_THERM_INTERRUPT. Hardware acknowledges the request by setting bit 25 in IA32_PACKAGE_THERM_STATUS. This series enables directed package thermal interrupts and designates one handler CPU per package using the CPU hotplug infrastructure. A new CPU is selected if the handler CPU goes offline."

All the small improvements continue adding up and ensuring a nice Intel CPU experience on Linux.

Technical Deep Dive

Current Thermal Interrupt Behavior

Currently, when a thermal event occurs at the package level, the interrupt is broadcast to all CPU cores in the package. This means that if you have a 16-core processor, all 16 cores will receive the thermal interrupt notification, even though only one core needs to handle the thermal event.

This broadcast approach creates several problems:

1. Resource Contention: Multiple cores racing to handle the same interrupt
2. Power Inefficiency: Idle cores being woken up unnecessarily
3. Cache Pollution: Multiple cores accessing shared data structures
4. Performance Impact: Context switches and cache invalidation

The New Directed Approach

The directed package thermal interrupts solve this by allowing only one designated CPU core to receive the thermal interrupt. The mechanism works as follows:

• A CPU opts in by setting bit 25 in the IA32_THERM_INTERRUPT MSR
• Hardware acknowledges by setting bit 25 in IA32_PACKAGE_THERM_STATUS
• The Linux kernel designates one handler CPU per package using CPU hotplug infrastructure
• If the handler CPU goes offline, a new one is automatically selected

Performance Benefits

This change should provide measurable improvements in several areas:

• Reduced Power Consumption: Fewer cores woken from idle states
• Lower Latency: Single core handling thermal events without contention
• Better Cache Efficiency: Single core accessing thermal data structures
• Improved Scalability: Benefits scale with core count

Hardware Support

The feature was recently added to the Intel Software Developer Manual, suggesting it's a relatively new capability. While the exact processor generations aren't specified in the Linux patches, the timing suggests it may first appear with:

• Nova Lake (client processors)
• Diamond Rapids (server processors)

However, the patches mention "newer" Intel CPUs, so the feature may appear across multiple generations.

Implementation Details

The Linux kernel implementation involves several key components:

1. MSR Configuration: Setting and monitoring the appropriate model-specific registers
2. CPU Selection Logic: Using existing CPU hotplug infrastructure to select handler cores
3. Fallback Handling: Automatic selection of new handler if current one goes offline
4. Backward Compatibility: Maintaining support for processors without this feature

Real-World Impact

For most users, this change will be largely transparent, but it contributes to the overall efficiency and performance of Intel processors on Linux systems. The reduction in unnecessary wakeups and resource contention can be particularly beneficial in:

• Data Centers: Where power efficiency and performance per watt are critical
• Mobile Devices: Where battery life is paramount
• High-Performance Computing: Where every cycle counts
• Homelab Environments: Where multiple workloads share resources

This is another example of how Intel continues to refine its processor architecture and how Linux kernel developers work to optimize support for new hardware features. While not as flashy as a new instruction set or core architecture, these incremental improvements add up to better performance, efficiency, and user experience over time.