参考下面两篇文章操作：
c - Whole one core dedicated to single process - Stack Overflow
第一步：Add the parameter isolcpus=[cpu_number] to the Linux kernel command line from the boot loader during boot. This will instruct the Linux scheduler not to run any regular tasks on that CPU unless specifically requested using cpu affinity.
被isolcpus指定的CPU不参与调度系统的负载均衡，带来的好处是有效地提高了孤立cpu上任务运行的实时性。该功能在保证孤立cpu上任务的运行，同时减少了其他任务可以运行的cpu资源，所以需要使用前对cpu资源进行规划。
修改方法如下：
系统启动后，/proc/cmdline显示修改的命令行已经生效，CPU2核被隔离开来：
查看系统运行情况：
可以看到有一些内核线程比如kworker/2:0-eve占用了CPU2,这是因为它指定了在CPU2上执行。启动系统时默认不使用CPU2,但并不是不可以使用,操作系统仍然可以显式指定使用2号CPU。
运行STRESS压力测试，此时系统负载情况如下图，可以看到，CPU2被完美的绕开了，即便其他CPU很忙，但是唯独CPU2这里占用率为0，查看进程掩码为0xfb,完美绕开了cpu2.
如果隔离多个核，下图隔离了2，3，4，5，6核，进程AFF掩码变成了0x83，效果更明显：
第二步，将优化应用绑定到CPU2上，设置AFFINITY为CPU2。
此时，CPU2的占用率开始有了变化，因为在CPU2上运行了我们指定affinity的进程，我们隔离了一个CPU，专门跑我们指定的进程，目的达到了。
此时监控进程的调度情况，发现其持续在CPU2上运行，中间没有发生过迁移。
对比另一个没有绑核的进程，可以发现其随时可能发生迁移，区别明显。
系统方面，挂在CPU2 ready queue上的就绪任务屈指可数，而且都是内核线程：
echo help > /proc/sysrq-trigger
echo t > /proc/sysrq-trigger
运行绑核的进程，可以看到其已经绑到了核CPU0上。
被隔离的核上的CFS队列是空的，也就是说，CFS队列上没有任务，下面显示隔离核7时，其就绪队列情况，可以看到，它只有rt_rq，dl_rq两条就绪队列。
当在核7上绑定STRESS进程后，情况发生了变化，核7上出现了/user.slice调度组队列和核本身的就绪队列两个队列：
第三步:设置中断亲和力，让所有的中断不再发送到核2上，保证核2只专心做我们指定的事情：/proc/irq/default_smp_affinity
通过以上三步操作，基本就能保证，除了内核默认分配给核上的进程之外，CPU2只跑我们指定AFFINITY的进程。此时CPU也不是完全不响应中断，它会响应一些本地中断，比如本地时钟，本地系统中断(计算异常，TLB等等）。
几个小时后的截图，可以看到126号中断和131号中断没有增长，说明中断亲和性设置生效了。
关于设置中断亲和力的扩展
linux中断相关信息通过/proc/interrupt节点和/proc/irq目录暴露给用户空间，用户可以基于暴露出来的文件进行相关配置操作，包括设置中断亲和性。
/proc/interrupt 内容包括系统支持的各类中断和异常的历史发生数据：
其中，每个IRQ默认的亲和性在文件/proc/irq/default_smp_affinity中:
经过测试，决定IRQ亲和性的并不是/proc/irq/default_smp_affinity文件，而是/proc/irq/#IRQ/smp_affinity文件。
修改中断亲和力：
以#1中断为例，默认情况下，其绑到CPU5上，现在我们想把它移到CPU1上处理。
进入到/proc/irq/1目录，查看其默认的中断亲和配置情况，smp_affinity和smp_affinity_list指定了哪些CPU能够关联到一个给定的IRQ源. 这两个文件包含了这些指定cpu的cpu位掩码(smp_affinity)和cpu列表(smp_affinity_list)情况，可以看到能够处理#1中断的CPU有0-5，和7，根据上图，当前选择实际处理的是CPU5。
片刻后，CPU5处理#1中断的数达到了2082个。
使用如下命令将#1中断的亲和力设置为CPU1处理：
root@zlcao-RedmiBook-14:/proc/irq/1# echo 2 > smp_affinity
root@zlcao-RedmiBook-14:/proc/irq/1# cat smp_affinity
02
root@zlcao-RedmiBook-14:/proc/irq/1# cat smp_affinity_list
1
此时在等片刻，查看#1号中断的处理情况:
此时发现，CPU5再处理到第2508次后，#1号中断迁移到CPU1上处理：
此时CPU1处理#1中断的次数不断累加，而CPU5的处理次数停在2508不再累加。
所以第三步修改default_smp_affinity文件设置中断亲和力有可能是无效的，这点要留意。
消除指定核上中断的最彻底的方法
上面介绍的消除核上中断的方法需要针对每个中断进行处理，并且处理方法是动态的，系统重启后，之前的配置都消失了，这里介绍的方法可以避免这两个缺点。
类似于核隔离，消除某个cpu上的时钟中断，可以指定“nohz_full”参数。修改启动命令行，添加：
isolcpus=6-7 nohz_full=6-7
重启后可以看到/proc/interrupts，6，7核上的中断明显少于其他CPU，不为0的那些中断可能是启动阶段，命令行参数生效前发生的。
cpu online/offline时watchdog被disable/enable.
每个没有被隔离的CPU上都有一个watchdog,在CPU上线，下线时可以单独控制。
不过nohz_full可能只在内核"CONFIG_NO_HZ_FULL=y"的前提下起作用。
- CONFIG_HZ_PERIODIC ##周期性tick。
- CONFIG_NO_HZ_IDLE ##在系统idle状态下，禁止tick。
- CONFIG_NO_HZ_FULL ##在系统idle或只有一个任务在运行的状态下，禁止tick。
默认状态下，内核的时钟tick配置为CONFIG_NO_HZ_IDLE，也就是在idle的情况下关掉时钟中断。
开启CONFIG_NO_HZ_FULL以支持全动态时钟系统，可以让单个实时任务性能更高，干扰越小。
另外NO_HZ_FULL需要和命令行参数配合使用，需要在kernel cmdline中指定要启动的CPU。
如，在一个16核CPU的系统上，通过cmdline指定nohz_full=1-15，表示所有核（除0核）使能全动态时钟tick。
打开CONFIG_NO_HZ_FULL后测试，可以看到处理器6，7上连续几秒钟都不来时钟中断。
运行压力测试，6，7核上每秒中断次数也都很少：
对比其他没有被隔离的核，其在压力测试下，每秒钟的本地中断频率为1000左右(CONFIG_HZ=1000)。
验证本地中断频率
sudo perf stat -C 6 -e irq_vectors:local_timer_entry taskset -c 6 stress -t 1 -c 1命令解释如下：
-C 6: perf 处理器6。
-e irq_vectors:local_timer_entry: 对应/sys/kernel/debug/tracing/events/irq_vectors/local_timer_entry，要分析的事件。
taskset -c 6: 将后续测试进程绑定到处理器6上。
stress -t 1 -c 1:进行压力测试，测试时长1秒，创建1个测试进程。
所以，上面的命令表示，在处理器6上，进行1秒钟的PERF测试，测试项目为irq_vectors:local_timer_entry，测试用例为1个stress进程，我们发现，评估其本地时钟中断的频率恰好在250周围附近变动，和CONFIG_HZ=250吻合。
统计CPU时钟频率
测试系统打开了CONFIG_HZ=1000和CONFIG_NO_HZ_FULL=y，可以发现，除了CPU0(可能是housekeeping cpu)时钟频率能够达到1000之外，其它的核心都进入了NO_HZ状态，HZ钟频打不满。
隔离的再狠一点，8核隔离调2-7核，只剩下0/1核，发现时钟中断只发生在核0/1上了。
总结
需要说明的是，上述隔离cpu的方法仅仅对用户空间的进程有效，对内核的进程无效，所以即便用户态不创建绑定隔离CPU的dedicate 进程，被隔离的cpu也并不是完全空闲的，它可能会执行内核态的一些人物，当前CPU节点上的文件交换操作。
参考文章
降低linux实时任务抖动&延迟_config_no_hz_full-CSDN博客
Documentation/admin-guide/lockup-watchdogs.rst
softlock_up以及时钟中断问题记录_nohz_full 功能-CSDN博客
https://www.cnblogs.com/yuanqiangfei/p/17825601.html
438
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
