linux定时器中断程序,timer - 实时Linux：禁用本地计时器中断 - 堆栈内存溢出

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中的migration / 1和优先级为99。也许这些进程在运行时会导致中断。 这解释了当我的进程进入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上，中断更少。 你知道为什么吗 ？