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，它很好结合了两点，分析内核时间延迟的变异。
