谈谈 Linux 内核的噪声

Linux 内核是广被使用的操作系统，从嵌入式家用设备，航空航天设备到超级计算机，到处都有 Linux 内核的身影，这归功于 Linux 内核丰富的配置带来的巨大灵活性。

网络虚拟化和软件定义网络的发展，也从另外一个方面证实了在网络设备如此专用的领域，Linux 内核也能发挥巨大作用，并且对网络设备领域带来可编程性的巨大便利，极大促进了网络设备领域的发展，5G 网络堆栈建立在这个范式之上。随着无人驾驶和物联网等实时系统的发展，对延迟要求越来越高。高性能计算(HPC)、实时任务和软件定义网络等需求需要 Linux 能够执行延迟敏感的任务。

为了达成这些目标，软硬件都要为高性能计算和实时性做配置。硬件需要在吞吐和延迟确定性之间做权衡，包括调整处理器的频率，省电模式和系统管理中断等。

对内核配置来说，就是要在系统中隔离出一些看家(house keeping) CPU, 这些看家上跑的任务包括内核线程，如 RCU 回调线程，内核中一些延迟任务线程，以及内核与用户态一些看守线程。一些中断也被放在看家 CPU 上。这样，在软件定义网络系统中，特定的隔离的 CPU 被用来执行特殊的网络功能虚拟化(NFV)。

虽然有需要确定性的任务被路由到这些特定的隔离的 CPU 上，仍然有一些 CPU 由调度分配用来执行通用的一般任务，这些 CPU 对延时确定性要求不高，不被隔离。为了提高这类需要延迟确定的系统的实时性，常常需要内核配置 PREEMPT_RT 以减少唤醒延迟。

这些对延迟敏感的系统评估是一件非常复杂的工作，评估这些系统的延迟变异是一件非常艰苦但重要的工作。这在高性能计算领域被称为系统噪声，在实时操作系统领域，被称为实时性。无论叫做什么，这件事的本质都是一样的，一个确定的工作是怎样被系统内各种复杂的软硬件组件干扰，进而产生非常复杂的时间延迟分布的。

怎样评估一个内核的噪声呢？大概有两种方法：设置合适的负载和基于追踪的方法。前者是基于任务的一种宏观测试方法，测试各种不同任务的时间分布，后者是一种微观的方法，检测同一个任务在执行时产生这种时间的分布的根源是什么。

这两种方法观察尺度不同，各有利弊，负载的方法能够就某个特定的任务给出时间分布特征，并且可以分析影响这个任务的时间特征的宏观因素。而基于追踪的微观方法，能分析出各个软件或者硬件过程时间延迟，但是在整个系统中如何还原出产生这些微观延迟的来源，是很难做到的。

因此很多时候，需要结合基于负载的方法和基于追踪的方法，才有可能接近事实真相。内核中有 osnoise 同时结合了基于负载的方法和基于追踪的方法，来评价和归因内核中的噪声。

这个工具是为高性能计算开发的，用于对隔离的 CPU 系统中，追踪微妙级的噪声。通过一系列对内核实时基础设施，调度，追踪子系统等的修改， sosnoise 最终在内核的 5.14 版本正式进入了 Linux 内核，在内核 5.17 中， 这个功能可以在用户态通过 rtla (Real-Time Linux Analysis) 工具集使用被内核开发者和系统管理者使用，这些人很容易通过这些工具测试它们的系统的噪声，或者扩展这些工具的功能。

为了理解 osnoise 在做什么， 我们先来看看噪声来源。

我们介绍下 Linux 内可以被称为任务的几种上下文。一般程序有 non-maskable interrupts (NMIs), maskable interrupts (IRQs), softirqs 和线程四种执行上下文。在 PREEMPT_RT 开启时，softirqs 线程化。我们没必要区分这些不同的执行流或者叫上下文，我们可以把它们统称为任务。这几种任务在 Linux 中遵循以下规则：

• 每个 CPU 的 NMI 抢断 IRQs，softirqs 和线程

• 每个 CPU 的 NMI 一旦发起，就必须执行完成才让出 CPU

• IRQs 抢断 softirqs 和线程

• 一旦一个 IRQ 开始处理， 它不会被另一个 IRQ 抢断

• Softirqs 可以抢断线程

• softirq 不能被另外一个软中断抢断

• 线程不能抢断 NMI, IRQs and sofirqs

我们接着介绍下 Linux 的调度器，Linux 有 5 个分层的调度器，调度所有的线程，不管这些线程是内核线程还是用户态线程，对调度器来说，都一视同仁，并没有什么不同。这 5 个调度器以一个固定的顺序作用来选出下一个要运行的线程。这些调度器按照执行顺序依次是：

第一个调度器为 stop machine 调度器，它在多 CPU 系统中用来实现负载均衡和热插拔等内核功能。

第二个调度器是 SCHED_DEADLINE，是一个基于 Earliest Deadline First 的 deadline 实时调度器。

第三个是一个 POSIX 兼容的固定优先级的实时调度器， 使用这个调度器的线程可以是 SCHED_RR 或者 SCHED_FIFO 类型的线程，SCHED_RR 为时间片轮转的线程，SCHED_FIFO 线程只有在挂起，执行结束，或者被抢占时才能才会释放 CPU 的使用。

第四个调度器是通用调度器，即 CFS 调度器，这个调度器调度的线程标记为 SCHED_OTHER。

第五个调度器为 IDLE 调度器， 当前面四个调度器没有线程调度到时，就调度到 idle thread 线程。

Linux 有一套丰富的追踪功能。可以追踪例很多内核功能函数， 这些追踪功能的广泛使用，他们并没有带来太大性能损耗，却给关心内核运行的人提供了很好的观察内核如何运行的窗口。ftrace，ebpf 和 systemtap 都是这些追踪系统的杰出代表。

以 HPC 程序来说明这个问题。正常 HPC 应用是一个程序在多份数据上运行的同一段代码(single-program multiple-data (SPMD) model), 如图所示：

上面是一个 HPC 的程序运行过程， A，B, C 运行同一段代码，它们计算完成后把数据发送给 D 进行接下来的计算。正常计算只有蓝色部分的局部计算，橙色部分的线程间同步，以及绿色的线程间通信，这是每个 CPU 上的线程实际做的工作，但是，系统中总是存在各种因素会打断程序在 CPU 上运行。因此，在上述蓝色局部计算的中间，总是会引入红色的部分，这些用户任务的运行总是被操作系统的一些系统任务打断，这些系统任务可能是 NMIs, IRQs 或者 softirqs，也可能是其它用户线程或者内核线程。

这些跟程序执行无关由系统引入的时间延迟的不确定性就是噪声，这些噪声让 A,B,C 三个相同的程序经历的时间也不同，对于 HPC 来说，就带来很大的延迟和性能惩罚，如果对于实时性很强的系统，可能带来的不只是性能惩罚，而是灾难。

从上面的讨论可以看出，不同的调度策略对局部 CPU 某个任务的执行延迟影响很大，严重影响每个并行任务的响应时间。这些被内核的系统活动引起的延迟其实就是操作系统噪声。全世界的超级计算机使用 Linux 作为内核，原因之一在于 Linux 可以通过配置，把 NMIs, IRQs 或者 softirqs，内核线程等系统活动局限在少数的几个核心上，而大部分其它核心用来跑真正的计算任务，这些跑计算任务的核心通过隔离和绑核，可以免受系统噪声和其它用户程序产生噪声的干扰，使其延时表现出好的多的确定性。

在软件定义网络实践中，发展出 DPDK 这种通用框架进行类似的噪声隔离工作，而 HPC 和其它实时系统中，也有类似的框架。虽然可以对 CPU 进行隔离，并且可以把所有 IRQ, softirqs 以及内核线程都移动到少数几个 CPU 核上， 对延迟特别敏感的任务进行精心配置却是一个非常有挑战的工作。因为还有很多每 CPU 的软件活动会干扰程序运行，比如调度器用的时钟中断，虚拟内存统计，网络包的处理等。这些噪声来源可以被精心的配置去掉，比如在内核配置里使能 NOHZ_FULL 去除时钟中断的干扰， 或者修改内核的代码或者算法去除相应的噪声干扰。

Linux 是个通用操作系统，它不是为延时敏感的应用而生的，但是 HPC, 实时操作系统这类希望利用 Linux 实现其苛刻目标的开发者们，不可能时刻去追踪 Linux 的修改对其延时干扰的影响。

大家习惯用一些实时或者延时敏感的 HPC 负载去度量 Linux 内核噪声，两个好用的工具就是 sysjitter 和 oslat。这些工具重复测量同一个任务的延时差异，比较它们的延时差异是否超过某个门限值。

这些工具用一些计算任务去测量和发现噪声的存在，但是并不会寻找它们的原因。要发现这些噪声的原因，我们需要内核的追踪系统去观察整个内核系统的运行。当然，追踪系统也会引入噪声，这就需要统计去寻找噪声的根本原因以抓住主要矛盾。

硬件本身的噪声也不少见，可能是因为共享硬件资源，打开了超线程，有比操作系统执行优先级更高的上下文，比如系统管理中断，这些不是操作系统本身引入的问题，但是他们可以被追踪系统看到。有的基于任务的测试能够看到的噪声很难被追踪系统复现，这些是比较头疼的问题，需要不断基于两者的数据进行长时间深入分析，以仔细还原时间到底去哪了。

总体而言，目前综合基于任务的测试和基于追踪的分析最好的工具是 osnoise，它很好结合了两点，分析内核时间延迟的变异。