TL; DR :将Linux内核实时与NO_HZ_FULL一起使用，我需要隔离一个进程以获得确定的结果，但是/proc/interrupts告诉我仍然存在本地计时器中断(以及其他中断)。如何禁用它？
较长版本:
我想确保程序不会被中断，所以我尝试使用实时Linux内核。
我使用的是Arch Linux的实时版本(AUR上的linux-rt)，并且修改了内核的配置以选择以下选项:
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ_FULL_ALL=y
CONFIG_RCU_NOCB_CPU=y
CONFIG_RCU_NOCB_CPU_ALL=y
然后我重新启动计算机，以使用以下选项在此实时内核上启动:
nmi_watchdog=0
rcu_nocbs=1
nohz_full=1
isolcpus=1
我还禁用了BIOS中的以下选项:
C state
intel speed step
turbo mode
VTx
VTd
hyperthreading
我的CPU(i7-6700 3.40GHz)具有4个内核(具有超线程技术的8个逻辑CPU)
我可以在/proc/interrupts文件中看到CPU0，CPU1，CPU2，CPU3。
CPU1由
isolcpus内核参数隔离，我想在此CPU上禁用本地计时器中断。尽管具有CONFIG_NO_HZ_FULL和CPU隔离(isolcpus)的实时内核足以做到这一点，但我尝试通过运行以下命令进行检查:
cat /proc/interrupts | grep LOC > ~/tmp/log/overload_cpu1
taskset -c 1 ./overload
cat /proc/interrupts | grep LOC >> ~/tmp/log/overload_cpu1
过载过程在哪里:
***overload.c:***
int main()
{
for(int i=0;i<100;++i)
for(int j=0;j<100000000;++j);
}
文件
overload_cpu1包含结果:LOC: 234328 488 12091 11299 Local timer interrupts
LOC: 239072 651 12215 11323 Local timer interrupts
含义651-488 = 163来自本地计时器的中断而不是0 ...
为了进行比较，我进行了相同的实验，但是更改了进程
overload运行的核心(我一直在观察CPU1上的中断):taskset -c 0 : 8 interrupts
taskset -c 1 : 163 interrupts
taskset -c 2 : 7 interrupts
taskset -c 3 : 8 interrupts
我的问题之一是为什么没有0个中断？当我的进程在CPU1上运行时，为什么中断次数更大？ (我的意思是，尽管我的进程是单独的，但我虽然NO_HZ_FULL会阻止中断:“CONFIG_NO_HZ_FULL = y Kconfig选项导致内核避免
通过单个可运行任务向CPU发送调度时钟中断”(https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt)
可能的解释是CPU1上还有其他进程正在运行。
我通过使用ps命令进行了检查:
CLS CPUID RTPRIO PRI NI CMD PID
TS 1 - 19 0 [cpuhp/1] 18
FF 1 99 139 - [migration/1] 20
TS 1 - 19 0 [rcuc/1] 21
FF 1 1 41 - [ktimersoftd/1] 22
TS 1 - 19 0 [ksoftirqd/1] 23
TS 1 - 19 0 [kworker/1:0] 24
TS 1 - 39 -20 [kworker/1:0H] 25
FF 1 1 41 - [posixcputmr/1] 28
TS 1 - 19 0 [kworker/1:1] 247
TS 1 - 39 -20 [kworker/1:1H] 501
如您所见，CPU1上有线程。
是否可以禁用这些进程？我想这是因为如果不是这种情况，NO_HZ_FULL将永远无法正常工作吗？
TS类的任务不会打扰我，因为它们在SCHED_FIFO中没有优先级，我可以将此策略设置为我的程序。
FF级和优先级小于99的任务也是如此。
但是，您可以看到SCHED_FIFO和优先级99中的migration/1。
这些过程在运行时可能会导致中断。这解释了当我的进程进入CPU0，CPU2和CPU3时的几个中断(分别为8,7和8个中断)，但是这也意味着这些进程不是很频繁地运行，因此没有解释为什么当我的进程运行时为什么会有很多中断在CPU1上(163个中断)。
我也进行了相同的实验，但是对重载过程使用了SCHED_FIFO，我得到了:
taskset -c 0 : 1
taskset -c 1 : 4063
taskset -c 2 : 1
taskset -c 3 : 0
在这种配置下，如果我的进程在CPU1上使用SCHED_FIFO策略，则中断更多，而在其他CPU上，中断更少。你知道为什么吗 ？
最佳答案
事实是，一个全不滴答的CPU(又称自适应滴答声，配置了nohz_full=)仍然会收到一些滴答声。
最值得注意的是，调度程序需要在隔离的完整无滴答CPU上安装一个计时器，以便每秒钟左右更新一些状态。
这是有据可查的限制(截至2019年):
(来源:Documentation/timers/NO_HZ.txt，请参阅2013年LWN文章(Nearly) full tickless operation in 3.10的某些背景知识)
测量本地计时器中断(/proc/interrupts中的LOC行)的一种更准确的方法是使用perf。例如:
$ perf stat -a -A -e irq_vectors:local_timer_entry ./my_binary
my_binary的线程固定到隔离的CPU上，这些线程不间断地使用CPU，而无需调用系统调用-持续2分钟。还有其他本地计时器滴答声的来源(当只有1个可运行任务时)。
例如，VM统计信息的收集-默认情况下，它们每秒钟收集一次。因此，我可以通过设置较高的值来减少LOC中断，例如:
# sysctl vm.stat_interval=60
另一个来源是定期检查不同CPU上的TSC是否不漂移-您可以使用以下内核选项禁用它们:
tsc=reliable
(如果您真的知道您的TSC不会漂移，请仅应用此选项。)
您可以通过使用ftrace记录跟踪(在运行测试二进制文件时)来找到其他来源。
由于它出现在注释中:是的，SMI对内核是完全透明的。它不会显示为NMI。您只能间接检测SMI。