谈一谈Linux让实时/高性能任务独占CPU的事

Posted 2021-08-31 从善若水

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了谈一谈Linux让实时/高性能任务独占CPU的事相关的知识，希望对你有一定的参考价值。

文章目录

谈一谈Linux让实时/高性能任务独占CPU的事
Part 1
- 工程需求
Part 2
- 用户态隔离
Part 3
- 内核态隔离
- - 中断
  - 内核态线程
Part 4
- 最佳实践指南

谈一谈Linux让实时/高性能任务独占CPU的事

原版文章

https://mp.weixin.qq.com/s/_NwWD5CM1tda6lJXYFjnSQ

内容简介

本文主要讨论在高实时要求、高效能计算、DPDK等领域，Linux如何让某一个线程排他性独占CPU；独占CPU涉及的线程、中断隔离原理；以及如何在排他性独占的情况下，甚至让系统的timer tick也不打断独占任务，从而实现最低的延迟抖动。

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是你最好的选择：