谈一谈Linux让实时任务独占CPU的事
本文主要讨论在高实时要求、高效能计算、dpdk等领域，linux如何让某一个线程排他性独占cpu；独占cpu涉及的线程、中断隔离原理；以及如何在排他性独占的情况下，甚至让系统的timer tick也不打断独占任务，从而实现最低的延迟抖动。
本文目录：
1. 工程需求
2. 用户态隔离
3. 内核态隔离
3.1 中断
3.2 内核线程
4. 最佳实践指南
part 1
工程需求
在一个smp或者numa系统中，cpu的数量大于1。在工程中，我们有时候有一种需求，就是让某个能够独占cpu，这个cpu什么都不做，就只做指定的任务，从而获得低延迟、高实时的好处。
比如在dpdk中，通过设置
grub_cmdline_linux_default=“isolcpus=0-3，5，7”
隔离cpu0，3，5，7，让dpdk的任务在运行的时候，其他任务不会和dpdk的任务进行上下文切换，从而保证网络性能最佳［1］。在realtime应用场景中，通过isolcpus=2隔离cpu2，然后把实时应用通过taskset绑定到隔离的核：
taskset-c 2 pn_dev
从而保证低延迟要求［2］。
part 2
用户态隔离
这个地方，我们可以看出，它们统一都使用了isolcpus这样一个启动参数。
实践是检验真理的唯一标准，下面我们来启动一个8核的arm64系统，运行ubuntu，并指定isolcpus=2这个启动参数：
系统启动后，我们运行下面简单的程序（启动8个进程运行while死循环）：
我们是8核的，现在又是运行8个进程，所以理论上来讲，负载均衡后，8个进程应该均分地运行在8个核上面，但是我们来看看实际的htop结果：
我们发现3（也就是cpu2）上面的cpu占用率是0.0%。这实证了cpu2已经被隔离，用户空间的进程不能在它上面跑。
当然，这个时候，我们可以通过taskset，强行把其中的一个a.out，绑定到cpu2上面去：
从上面命令的结果看出，663原本的affinity list只有0，1，3-7是没有2的，而我们强行把它设置为了2，之后再看htop，cpu2上面占用100%：
通过上面的实验，我们明显可以看出isolcpus=2使得cpu2上无法再运行用户空间的进程了（除非手动设置affinity）。
part 3
内核态隔离
中断
但是，能在cpu2上面运行的，不是只有用户态的任务，还可以有内核线程、中断等，那么isolcpus=能否隔离内核线程和中断呢？
对于中断，我们特别容易查看，就是实际去验证每个irq的smp_affinity就好了：
从上图明显可以看出，对于44、47号这种外设的中断，linux内核把smp_affinity设置为了fb（11111011），明显避开了cpu2，所以，实际外设中断也不会在cpu2发生，除非我们强行给中断绑核，比如让44号中断绑定到cpu2：
echo 2 》/proc/irq/44/smp_affinity_list
之后，我们发现44号中断在cpu2可以发生：
但是，系统的timer中断、ipi，由于是linux系统的运行基石，实际还是要在cpu2上面运行的。这里面最可能给任务带来延迟抖动的，自然是timer tick。
下面我们重点探讨下tick的问题，由于linux一般情况下，已经配置idle状态的no_hz tickless，所以cpu2上面什么都不跑的时候，实际timer中断几乎不发生。
下面，我们还是在isolcpus=2的情况下，运行前面那个8个进程的a.out，默认情况下没有任务会占用cpu2。通过先后运行几次cat /proc/interrupts | head 2，我们会看到其他core的timer中断频繁发生，而cpu2几乎不变，这显然是idle时候的no_hz在发挥省电的作用：
但是，一旦我们放任务到cpu2，哪怕只是放1个，就会发现cpu2上面的timer中断开始增加：
这说明一点，哪怕隔离的cpu上面只有一个线程去跑，timer tick就会开始跑，当然，这个timer tick也会频繁打断这一个线程，从而造成大量的上下文切换。你肯定会觉得linux怎么这么傻，既然只有一个人，那也没有时间片分片的必要，不需要在2个或者多个任务进行时间片划分地调度，为啥还要跑tick？其实原因是我们的内核默认只是使能了idle的no_hz：
我们来重新编译一个内核，使能no_hz_full：
当我们使能了no_hz_full后，linux支持在cpu上仅有1个任务的时候，是可以no_hz的。但是有2个就傻眼了，所以这个“full”也不是真地full［3］。这当然也可以理解，因为有2个就涉及到时间片调度的问题。什么时候应该使能no_hz_full，内核文档documentation/timers/no_hz.rst有明确地“指示”，只有在实时和hpc等的场景，才需要，否则默认的no_hz_idle是你最好的选择：
我们重新编译了内核，选中了no_hz_full，下面启动linux，注意启动的时候参数添加nohz_full=2，让cpu2支持no_hz_full：
重新运行cpu2只有一个任务的场景，看看它的timer中断发生情况：
发现cpu2上面的tick稳定在188上面，这样相信你会更加开心，因为你独占地更加彻底了！
下面，我们再放一个task进去cpu2，有2个任务的情况下，cpu2上面的timer tick开始增加：
不过，这或许不是个问题，因为我们说好了“独占”，1个任务独占的时候，timer tick不来打扰，应该已经是非常理想的情况了！
内核态线程
内核态的线程其实和用户态差不多，当它们没有绑定到隔离的cpu的时候，是不会跑到隔离cpu运行的。下面用笔者在内核里面添加的dma_map_benchmark来做实验［4］，开启16个内核线程来进行dma map和unmap（注意我们只有8个核）：
。/dma_map_benchmark -s 120 -t 16
我们看到cpu2上面的cpu占用也是0：
内核里面的dma_map_benchmark线程在狂占cpu0-1， 3-7，但是就是不去占cpu2：
但是，内核线程如果用kthread_bind_mask（）类似api把线程绑定到了隔离的cpu，则情况就不一样了，这就类似用taskset把用户态的任务绑定到cpu一样。
part 4
最佳实践指南
对于实时性要求高、高性能计算等场景，如果要让某个任务独占cpu，最理想的选择是：
1. 采用isolcpus隔离cpu
2. 将指定任务绑定到隔离cpu
3. 小心意外地把中断、内核线程绑定到了隔离cpu，排查到这些“意外”分子
4. 使能no_hz_full，则效果更佳，因为连timer tick中断也不打扰你了。
原文标题：宋宝华：谈一谈linux让实时/高性能任务独占cpu的事
文章出处：【微信公众号：linuxer】欢迎添加关注！文章转载请注明出处。
facebook数据泄露事件致人员架构重组 将成立区块链业务部门
如何利用区块链和智能合约技术使实现自动化交易
oppo vivo超越华为尚难，但是已经赶超小米
位移传感器在自动调焦单元有什么应用
为何选择车载以太网 车载以太网技术的演进
谈一谈Linux让实时任务独占CPU的事
邬贺铨：今年5G定位精度将提升0.3米
被动元器件正延长“波动期” 缺货涨价又将延续？
防静电工作台安装步骤
日本全力争夺电动汽车充电国际化标准的主权
华为如何估值？对标苹果或许靠谱
齐齐哈尔坍塌事故，为工地规范作业敲响警钟
上海喵呜科技为什么要进入AR儿童互动娱乐行业？
直接式TPMS系统,直接式TPMS系统原理是什么
随钻测井中的随钻声波测井迎来了巨大发展
华为调侃在美所售手机享100%折扣
4K电视慢慢变得丰富 8K电视开始普及
工程布线时常用材料的计算方法
区块链解决方案将如何用于证券交易所的工作
828 B2B企业节软通动力华为云渠道交流会（陕西场）圆满落幕
本文目录：
1. 工程需求
2. 用户态隔离
3. 内核态隔离
3.1 中断
3.2 内核线程
4. 最佳实践指南
part 1
工程需求
在一个smp或者numa系统中，cpu的数量大于1。在工程中，我们有时候有一种需求，就是让某个能够独占cpu，这个cpu什么都不做，就只做指定的任务，从而获得低延迟、高实时的好处。
比如在dpdk中，通过设置
grub_cmdline_linux_default=“isolcpus=0-3，5，7”
隔离cpu0，3，5，7，让dpdk的任务在运行的时候，其他任务不会和dpdk的任务进行上下文切换，从而保证网络性能最佳［1］。在realtime应用场景中，通过isolcpus=2隔离cpu2，然后把实时应用通过taskset绑定到隔离的核：
taskset-c 2 pn_dev
从而保证低延迟要求［2］。
part 2
用户态隔离
这个地方，我们可以看出，它们统一都使用了isolcpus这样一个启动参数。
实践是检验真理的唯一标准，下面我们来启动一个8核的arm64系统，运行ubuntu，并指定isolcpus=2这个启动参数：
系统启动后，我们运行下面简单的程序（启动8个进程运行while死循环）：
我们是8核的，现在又是运行8个进程，所以理论上来讲，负载均衡后，8个进程应该均分地运行在8个核上面，但是我们来看看实际的htop结果：
我们发现3（也就是cpu2）上面的cpu占用率是0.0%。这实证了cpu2已经被隔离，用户空间的进程不能在它上面跑。
当然，这个时候，我们可以通过taskset，强行把其中的一个a.out，绑定到cpu2上面去：
从上面命令的结果看出，663原本的affinity list只有0，1，3-7是没有2的，而我们强行把它设置为了2，之后再看htop，cpu2上面占用100%：
通过上面的实验，我们明显可以看出isolcpus=2使得cpu2上无法再运行用户空间的进程了（除非手动设置affinity）。
part 3
内核态隔离
中断
但是，能在cpu2上面运行的，不是只有用户态的任务，还可以有内核线程、中断等，那么isolcpus=能否隔离内核线程和中断呢？
对于中断，我们特别容易查看，就是实际去验证每个irq的smp_affinity就好了：
从上图明显可以看出，对于44、47号这种外设的中断，linux内核把smp_affinity设置为了fb（11111011），明显避开了cpu2，所以，实际外设中断也不会在cpu2发生，除非我们强行给中断绑核，比如让44号中断绑定到cpu2：
echo 2 》/proc/irq/44/smp_affinity_list
之后，我们发现44号中断在cpu2可以发生：
但是，系统的timer中断、ipi，由于是linux系统的运行基石，实际还是要在cpu2上面运行的。这里面最可能给任务带来延迟抖动的，自然是timer tick。
下面我们重点探讨下tick的问题，由于linux一般情况下，已经配置idle状态的no_hz tickless，所以cpu2上面什么都不跑的时候，实际timer中断几乎不发生。
下面，我们还是在isolcpus=2的情况下，运行前面那个8个进程的a.out，默认情况下没有任务会占用cpu2。通过先后运行几次cat /proc/interrupts | head 2，我们会看到其他core的timer中断频繁发生，而cpu2几乎不变，这显然是idle时候的no_hz在发挥省电的作用：
但是，一旦我们放任务到cpu2，哪怕只是放1个，就会发现cpu2上面的timer中断开始增加：
这说明一点，哪怕隔离的cpu上面只有一个线程去跑，timer tick就会开始跑，当然，这个timer tick也会频繁打断这一个线程，从而造成大量的上下文切换。你肯定会觉得linux怎么这么傻，既然只有一个人，那也没有时间片分片的必要，不需要在2个或者多个任务进行时间片划分地调度，为啥还要跑tick？其实原因是我们的内核默认只是使能了idle的no_hz：
我们来重新编译一个内核，使能no_hz_full：
当我们使能了no_hz_full后，linux支持在cpu上仅有1个任务的时候，是可以no_hz的。但是有2个就傻眼了，所以这个“full”也不是真地full［3］。这当然也可以理解，因为有2个就涉及到时间片调度的问题。什么时候应该使能no_hz_full，内核文档documentation/timers/no_hz.rst有明确地“指示”，只有在实时和hpc等的场景，才需要，否则默认的no_hz_idle是你最好的选择：
我们重新编译了内核，选中了no_hz_full，下面启动linux，注意启动的时候参数添加nohz_full=2，让cpu2支持no_hz_full：
重新运行cpu2只有一个任务的场景，看看它的timer中断发生情况：
发现cpu2上面的tick稳定在188上面，这样相信你会更加开心，因为你独占地更加彻底了！
下面，我们再放一个task进去cpu2，有2个任务的情况下，cpu2上面的timer tick开始增加：
不过，这或许不是个问题，因为我们说好了“独占”，1个任务独占的时候，timer tick不来打扰，应该已经是非常理想的情况了！
内核态线程
内核态的线程其实和用户态差不多，当它们没有绑定到隔离的cpu的时候，是不会跑到隔离cpu运行的。下面用笔者在内核里面添加的dma_map_benchmark来做实验［4］，开启16个内核线程来进行dma map和unmap（注意我们只有8个核）：
。/dma_map_benchmark -s 120 -t 16
我们看到cpu2上面的cpu占用也是0：
内核里面的dma_map_benchmark线程在狂占cpu0-1， 3-7，但是就是不去占cpu2：
但是，内核线程如果用kthread_bind_mask（）类似api把线程绑定到了隔离的cpu，则情况就不一样了，这就类似用taskset把用户态的任务绑定到cpu一样。
part 4
最佳实践指南
对于实时性要求高、高性能计算等场景，如果要让某个任务独占cpu，最理想的选择是：
1. 采用isolcpus隔离cpu
2. 将指定任务绑定到隔离cpu
3. 小心意外地把中断、内核线程绑定到了隔离cpu，排查到这些“意外”分子
4. 使能no_hz_full，则效果更佳，因为连timer tick中断也不打扰你了。
原文标题：宋宝华：谈一谈linux让实时/高性能任务独占cpu的事
文章出处：【微信公众号：linuxer】欢迎添加关注！文章转载请注明出处。
facebook数据泄露事件致人员架构重组 将成立区块链业务部门
如何利用区块链和智能合约技术使实现自动化交易
oppo vivo超越华为尚难，但是已经赶超小米
位移传感器在自动调焦单元有什么应用
为何选择车载以太网 车载以太网技术的演进
谈一谈Linux让实时任务独占CPU的事
邬贺铨：今年5G定位精度将提升0.3米
被动元器件正延长“波动期” 缺货涨价又将延续？
防静电工作台安装步骤
日本全力争夺电动汽车充电国际化标准的主权
华为如何估值？对标苹果或许靠谱
齐齐哈尔坍塌事故，为工地规范作业敲响警钟
上海喵呜科技为什么要进入AR儿童互动娱乐行业？
直接式TPMS系统,直接式TPMS系统原理是什么
随钻测井中的随钻声波测井迎来了巨大发展
华为调侃在美所售手机享100%折扣
4K电视慢慢变得丰富 8K电视开始普及
工程布线时常用材料的计算方法
区块链解决方案将如何用于证券交易所的工作
828 B2B企业节软通动力华为云渠道交流会（陕西场）圆满落幕