为何启用核心隔离的Linux仍每秒中断处理一次？

核心原因：实时调度带宽限制触发 #

你遇到的每秒50ms规律中断，最可能是Linux默认的实时调度带宽限制机制导致：

• 内核默认配置中，kernel.sched_rt_period_us=1000000（周期1秒），kernel.sched_rt_runtime_us=950000（实时任务每秒最多可运行950ms），剩余50ms会强制剥夺实时任务的CPU使用权——即便隔离核心上没有其他非实时任务，这个机制依然会触发。
• 带宽控制的检查与执行依赖本地定时器中断（Local timer interrupts）触发，所以你会看到该中断计数在应用运行时增长，且中断时长刚好匹配50ms的限制窗口。

若你的PREEMPT_RT内核版本较旧，nohz_full的实现可能存在遗留tick触发逻辑，但结合50ms的规律时长，带宽限制是首要嫌疑。

可行控制方法 #

1. 关闭实时调度带宽限制 #

仅在隔离核心专用于该实时任务时推荐此操作（避免非隔离核心上的实时任务饿死其他进程）：

• 临时生效：

  echo -1 > /proc/sys/kernel/sched_rt_runtime_us
  

• 永久生效（编辑/etc/sysctl.conf添加以下内容后执行sysctl -p）：

  kernel.sched_rt_runtime_us = -1
  

2. 验证nohz_full与核心隔离的正确性 #

确保内核启动参数配置完全生效：

• 检查目标核心的nohz_full状态（X为你的隔离核心编号）：

  cat /sys/devices/system/cpu/cpuX/cpufreq/nohz_full
  

  正常输出应为1。
• 确认核心隔离状态：

  cat /sys/devices/system/cpu/isolated
  

  输出应包含你的隔离核心编号。

3. 升级PREEMPT_RT内核至稳定版本 #

若上述操作后仍存在问题，建议升级到最新的稳定PREEMPT_RT内核版本——新版本对nohz_full和实时调度的兼容性更好，可能修复旧版本中的tick残留问题。

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