linux VS 轻量级多内核(IHK/McKernel)

本文章翻译原论文来自：https://bgerofi.github.io/papers/bgerofi-SC21.pdf。本文仅用作分享，无任何商业用途盈利，如有侵权，请联系作者删除。

摘要

研究目的：探索轻量级内核（LWK）操作系统在极端规模下是否能够超越Linux的性能。

方法：开发了IHK/McKernel，一个为HPC设计的轻量级多内核操作系统，并在两台高端超级计算机上部署，与Linux性能进行比较。

结果：在适度调整的Linux环境中，McKernel显著优于Linux（高达约2倍性能），而在Fugaku上，McKernel平均提速4%，部分实验中LWK性能超过Linux达29%。

研究背景与动机

在大规模超级计算机上执行的并行科学应用的最普遍运行时行为是计算和通信阶段的交替，也称为批量同步并行执行。在大规模超级计算机上运行批量同步应用时，操作系统管理任务可能会干扰应用程序进程的执行，从而对整体性能产生不利影响。这些非应用程序进程(操作系统守护进程、内核守护进程、中断处理等)造成的应用程序执行延迟统称为操作系统噪声，也成为操作系统抖动。下图显示了操作系统噪声对并行应用程序的影响。

添加图片注释，不超过 140 字（可选）

• 轻量级内核因其出色的可扩展性、可预测性和较低的操作系统抖动，有望实现而被认为在HPC中具有潜力。

• 多内核操作系统被提出以解决LWK的不足，同时保留Linux/POSIX API的兼容性。

测试平台概述

• Oakforest-PACS(以下简称OFP)：基于Intel Xeon Phi的超级计算机，运行适度调整的Linux发行版。

• Fugaku：基于Fujitsu A64FX CPU的超级计算机，运行高度调整的Linux环境，当时世界上最快的超级计算机。 具体的测试平台配置如下：

添加图片注释，不超过 140 字（可选）

Fugaku上的Linux性能扩展

优化应用程序性能的总体方法

总体方法是尽可能避免对RHEL提供的Linux内核源代码进行自定义修改。这一决策部分是由于我们在K计算机上的操作经验，其中自定义内核更改阻止了我们跟随主线内核的发展，由于可维护性问题。当Linux内核的修复绝对必要时，我们会将补丁直接推广到RHEL发行版，而不是独立应用。Fugaku为高性能计算应用提供了一个可扩展的执行环境。为了提供这样的环境，系统操作开销必须被降低。具体来说，我们使用以下技术来实现这一目的。

容器化

在Fugaku上，所有应用程序都在Docker容器中运行。用户可以使用系统管理员定义的容器映像，或者他们的作业将在看似在宿主Linux上运行的模式下执行。在任何情况下，Docker在底层创建cgroups来管理容器的计算资源。应用程序cgroup用于限制应用程序内存使用，并将用户进程绑定到特定核心和非均匀内存访问（NUMA）域。此外，我们为系统进程创建了一个专用的cgroup，以隔离系统CPU和内存。

虚拟NUMA节点

在A64FX上，系统固件引入了将物理地址空间划分为系统和应用程序区域的技术，这些区域被暴露为不同的NUMA域给Linux内核。我们称这种技术为虚拟NUMA节点。内存碎片化是影响性能的一个重要因素，它发生在新分配的内存区域已经被使用过的情况下。这样的分配可能会因此降低未来内存分配的性能。虚拟NUMA节点技术确保非应用程序进程的内存分配不能使用应用程序专用的内存区域，从而减轻由内存碎片化导致的性能下降。

大页支持

对于使用大量内存的应用程序来说，虚拟内存转换的成本(即TLB和硬件页表走行)会影响执行性能。我们在正常页面大小的基础上，有限考虑较大页面(巨页)的后备内存分配。巨页可降低地址转换换过程的成本，提高内存访问性能。

ARM64支持多种基本页面大小，在典型的aarch64系统的基础页面大小为4KB,单RHEL使用的基础页面大小为64KB.ARM64还提供了一个名为“页表-连续位”的特殊功能，如果设置了每个页表项中的指定位，就可以通过单个TLB项缓存32个物理连续页的虚拟地址到物理地址的转换，从而大大减少TLB错失。

Linux支持两种使用大页面的方法，即透明大页面（THP）和hugeTLBfs.在基础页面大小为64KB的情况下，使用连续位会产生2MB大小的大型页面。常规的大型页面为512MB.但是512MB大小的大页面很容易导致内存碎片问题，并使大页面的利用率普遍偏低。由于 Linux只支持hugeTLBfs中的连续位功能，而不支持THP实现，因此选择在Fugaku上使用hugeTLB。通常，hugeTLBfs会在启动时保留一个大型页面池以确保其可用性，这反过来又限制了系统中可用的正常页面数量。这对于那些不需要大型页面的应用程序（需要进行大量小型动态分配的应用程序）来说是个不利因素。为了满足这两种需求，启用了hugeTLBfs超量分配功能，无需预留内存池，并在运行时由buddy分配大型页面。然而，内存cgroup与hugeTLBfs的集成度不够，无法限制超量分配所分配的剩余大页面的使用。为了解决这个问题，我们通过内核模块在cgroup实现中挂接了一个Linux内核函数，以覆盖默认行为，并将剩余的hugeTLBfs页面释放地计入内存cgroup.

Fugaku的运行时系统与linux内核的hugeTLBfs设施进行了强有力的整合。它使所有进程内存区域都能使用大型页支持内存，如静态数据(.data和.bss)、堆栈区域以及堆(主要通过mmap()系统调用管理的动态内存区域)分配方案(即基于预分配或需求分页)可由特定的环境变量控制。

NUMA感知进程和线程绑定

A64FX节点拓扑结构围绕4个应用numa展开，每个域由12个CPU内核。为了最大限度地提高数据局部性，Fugaku的作业调度程序会根据每个节点的进程数自动将MPI进程绑定到特定的MUNA域，用户无需处理MPI实现所提供的复杂进程绑定接口。我们注意到，高级用户可以选择禁用默认绑定行为，并使用标准的Linux接口（如numactl）

硬件屏障

A64FX硬件提供了一种名为硬件屏障的并行应用程序同步方法，以加速节点内进程和/或线程之间的同步。对硬件屏障功能的支持被集成到Fugaku的运行时系统中，例如，集成到OpenMP实现中。

操作系统噪音消除技术

与RedHat合作降低操作系统噪音，以利用标准发行版的优势，避免对Linux内核进行定制修改。本章主要介绍使用方法。通过将系统资源划分为系统CPU核心分区和应用核心分区，并将系统绑定到前一个分区，将应用任务绑定到后一个分区，可以消除大部分操作系统噪音。具体来说，一下硬件资源被划分为系统片和应用片。

CPU内核 AFX处理器除了48个应用内核外，还有2-4个辅助进程，系统进程，比如操作系统守护进程与系统内核绑定，而应用程序进程则通过使用cgroups与应用程序内核绑定。通过配置相关的procfs文件(如/proc/irq/IRQ_NUMBER/smp_affnity),可将副IRQ路由到辅助核心。此外，kworker任务也可以通过其sysfs接口更改CPU亲和值，从而与辅助内核绑定。

内存 物理内存地址空间通过虚拟NUMA节点分为系统区域和应用区域。通过Linux内核的cgroup工具，系统进程绑定到系统区域，应用进程绑定到应用区域。

CPU缓存 通过使用A64FX的专用缓存块分区功能（扇区缓存），缓存块也被分为系统区和应用区。通过使用这一系统硬件特性，辅助内核被绑定到系统区域，而应用内核则被绑定到应用区域。

硬件资源的严格划分对减少操作系统内部活动与应用程序进程之间的干扰有着深远的影响。然而，各种软件干扰依然存在。

内核空间技术

为了识别干扰应用程序代码的内核模式任务，我们使用执行时间分析和ftrace，即Linux内核的调用跟踪功能。这些干扰任务可以通过完全禁用它们、减少它们的调用频率和/或将它们绑定到辅助CPU核心来抑制。例如，ftrace分析揭示了在使用blk-mq时，即使未绑定的kworker任务被绑定到辅助核心，块I/O处理的内核线程也会被派生到应用核心，因为它们的绑定是由内核中的专用数据结构（即，struct blk_mq_hw_ctx.cpumask）控制的。为了强迫它们特定处理器核心，我们明确更新了上述CPU掩码。

另一个值得注意的问题是定期访问性能监控单元（PMU）计数器，例如通过perf_event_open()系统调用获得的计数器。我们发现PMU计数器在所有CPU核心上被读取，即使访问是由绑定到辅助CPU核心的进程发起的。经过仔细调查，我们发现Fujitsu技术计算套件（TCS），一个提供E级系统操作和应用程序开发环境的中间件产品，发起了这些PMU访问操作。TCS作业操作软件收集PMU计数器以获取执行周期数、浮点指令操作数、内存读取请求、内存写入请求和睡眠周期数。我们通过提供一个命令来解决这个问题，允许用户在每个作业的基础上停止自动读取PMU计数器，从而消除了隐含的干扰。

用户空间技术

操作系统噪音通常是指由于操作系统内核(中断处理程序)中的活动而导致的应用程序代码执行过程中的中断。然而，这还不是全部。在多核系统中，运行在一个CPU内核上的操作系统代码可能会影响运行在另一个CPU内核上的应用程序的执行时间。通过使用CPU的性能计数器分别捕捉用户空间和内核空间的退役指令数和执行时间，可以确认是否存在此类噪声。如果在内核空间执行的指令数量增加，则可将此类噪声归因于操作系统的处理，如中断或页面故障处理程序。另一方面，当硬件共享或硬件内部争用导致执行时间增加时，用户空间和内核空间中执行的指令数都没有变化，只有执行时间增加。

由于多个CPU内核共享到主存储器/末级高速缓存的内存带宽，因此可能会产生这种干扰。在Fugaku中，TLB刷新处理对性能也有很大的影响，因此需要采取对策。与向特定处理器内核发送IPI以进行显式远程TLB失效不同，ARM64 ISA为TLB flush指令(即TLBI)提供了一个特殊操作符，以便在整个Inner-Sharable域(包括新品上的所有CPU内核)中执行失效操作。在Fugaku使用的A64FX上，由于A64FX的TLB缓存相对较大，我们发现执行该指令会影响其他CPU内核的性能。实验证实，在AFX中，一条TLB刷新指令会产生约200ns的延迟。在Linux上，一些释放大量内存的操作(如Go运行时系统的垃圾回收和进程终止操作)会导致数百到数千次连续的TLB刷新，从而产生数百微妙的噪声。

为了解决这个问题，与Redhat合作，对Linux进行了上游修改，以减少刷新广播，并将改进措施纳入RHEL8.2,专门用于fugaku的运行。该补丁通过使用只影响一个内核的TLB刷新指令，减少了TLB刷新处理，而不会对所有线程所在单个CPU内核上的进程（如单线程进程）进行TLB刷新广播。与其他ISA(比如x86_64和SPARC64)一样，也可以通过结合IPI和本地TLB刷新的软件来实现所有TLB刷新处理。但是ARM64在设计之初就采用了相对较快的硬件实施方式，这样所有处理器内核的TLB刷新处理都可以在一条指令中调用，而软件实现多内核TLB刷新处理的速度明显慢于硬件实现。因此，我们只减少了为在单CPU内核上执行的进程广播刷新TLB的不必要过程，并继续使用基于广播的指令在多个CPU内核上刷新TLB。在TCS中，系统运行所需要的所有组件(如操作系统守护进程和中断)都绑定到一个特定的处理器内核上。

IHK/McKernel

本节概述IHK/MCKERNEL并介绍针对Fugaku系统最新发展。

IHK/MCKERNEL多内核操作系统由两个主要部分组成。一个名为异构内核接口(IHK)的底层软件基础架构提供了在多核环境中分割资源（如CPU内核和物理内存）的能力，并能管理轻量内核的所有资源。McKernel是在IHK基础上开发的轻量级协同内核。多内核架构概览如图：

添加图片注释，不超过 140 字（可选）

IHK能够动态分配和释放主机资源，更改配置时无需重启主机。它是以Linux内核模块集合的形式实现的，无需对Linux内核本身进行任何修改，因此可以在各种Linux发行版本上直接部署多内核堆栈。除了资源和LWK管理外，IHK还提供了一个内核间通信（IKC）层，用于实现系统调用委托。

McKernel是从零开发的，虽然它是专门为高性能计算工作负载而设计的。它保留了于Linux兼容的应用程序二进制接口(ABI)，因此它可以执行未经修改的Linux二进制文件。无需要重新编译应用程序或任何McKernel专用库。McKernel只实现了一小部分对性能敏感的系统调用，其余的操作系统服务都委托给了Linux。具体来说，McKernel实现了内存管理，支持进程和多线程，有一个简单的轮循合作(无tick)调度器，并支持标准POSIX信号。它还实现了进程间内存映射，并提供了访问硬件性能计数器的接口。

在McKernel上执行的每一个操作系统进程都有一个在Linux上运行的进程，我们称之为代理进程。代理进程的主要作用是协助系统调用卸载。从本质上讲，他代表应用程序提供执行上下文，以便在Linux中调用已关闭的系统调用。代理进程还为Linux提供了维护各种状态信息的手段，而这些状态信息必须由协同内核来跟踪。例如，McKernel没有文件描述符的概念，但它只是返回在执行open()系统调用期间从代理进程接收到的数字。实际打开的文件集(文件描述表、文件位置等)由Linux内核管理。依靠代理进程，McKernel不仅以卸载系统调用的形式（例如，通过write()或者ioctl()）提供对Linux设备驱动程序的透明访问，而且还通过直接的设备映射。

Fugaku的开发

IHK/McKernel最初是为x86开发的。Fugaku的部分工作是将多内核操作系统一直到Fugaku的硬件上，即支持aarch64 ISA和所有ARM特殊系统级要求。此外，我们还将IHK/McKernel集成到Fugaku的容器运行时和批处理作业提交系统中。Fugaku运行富士通开发的专有作业调度程序。在OFP中，启动IHK/McKernel只需要在特定作业的序幕和尾声中调用几个特权模式脚本，而在Fugaku中，IHK/McKernel与富士通环境的集成要紧密得多。这主要是Fugaku平台的独特性（例如4.1中写的硬件障碍，进程放置方式，与MPI的交互等）。我们可以将LWK视为插件替换Linux内核的cgroup设施，因为它增加了内核级别专门化的能力。与容器相结合，可以定制用户空间组件，多内核+容器方法可以实现整个软件堆栈的专门化。

最后，McKernel的另一个值得注意的扩展是Tofu PicoDriver。在高层次上，Tofu网络的系统编程接口提供了与Infiniband或Intel的OmniPath类似的抽象，但在实现层面上有许多细微的差异。例如，所谓的STAGs的注册，是通过对Tofu驱动程序的ioctl()调用来执行的Tofu驱动程序。因为在我们的多内核的框架中，默认情况下这是卸载到Linux上的，他引入了额外的延迟。为了消除这样的开销，开发了一个类似于OmmiPath的PicoDriver的拆分驱动基础设施。

评估

实验环境

除了第3节中描述的平台外，我们提供了本文中使用的确切软件环境的更多细节。对于在OFP上的所有实验，我们将KNL处理器配置为Quadrant flat模式；即，MCDRAM和DDR4 RAM在不同的物理内存位置寻址，并出现为不同的NUMA域。应用程序使用Intel编译器19.0.3.199编译，并使用Intel MPI版本2019 Update 3 Build 20190214环境。对于McKernel测量，我们部署了IHK和McKernel，提交哈希分别为3bd05和da77a。我们利用IHK的资源分区功能动态保留处理器核心和物理内存。在Fugaku上，我们将第3节和第4节中描述的Linux环境与IHK和McKernel提交哈希797a2和b9edb进行比较。我们的实验中使用的TCS版本是1.2.30a，这是Fugaku早期访问计划中使用的版本。IHK/McKernel是开源的，并且可以在以下网址公开获取：https://github.com/RIKEN-SysSoft/mckernel。

基准测试和应用程序

对于噪音测量，我们使用Fixed Work Quanta（FWQ）基准测试。FWQ在循环中执行固定量的工作，其中只包含计算，不访问内存也不执行文件I/O，它记录每个循环迭代的执行时间。系统噪音可以通过这些值的差异来测量。在我们的所有FWQ测量中，我们将基准测试配置为大约6.5ms的运行时间，这是在Fugaku上配置低于10ms的最大值。OFP使用相同的目标间隔来表示经过的时间。至于应用程序级别的评估，我们使用以下代码。

AMG2013是并行代数多网格求解器，用于解决来自非结构化网格问题的线性系统。代码是用ISO标准C语言编写的。

Milc是MIMD格子计算（MILC）合作组织编写的一组代码的一部分，用于研究量子色动力学（QCD），这是亚原子物理中强相互作用的理论。它在MIMD并行机上执行四维SU(3)格子规范理论的模拟。强相互作用负责将夸克束缚成质子和中子，并使它们在原子核中保持在一起。

Lulesh是Livermore非结构化拉格朗日显式冲击波动力学基准测试，它是DARPA UHPC计划中的五个挑战问题之一，由LLNL定义和实现，并且自那时以来已成为DOE共同设计努力中的一个广泛研究的代理应用程序，用于E级计算。

LQCD基准测试了一个大型稀疏系数矩阵的线性方程求解器的性能，该矩阵出现在格子量子色动力学（QCD）模拟中，解释了质子和中子的性质，以基本粒子夸克和胶子为单位。四维（空间和时间）坐标被格点化，通过有限差分方法将夸克的运动方程转换为大规模线性方程。它使用BiCGStab算法求解O(a)改进的Wilson-Dirac夸克的方程。

GeoFEM通过并行有限元方法（FEM）解决简单的立方体几何中的3D线性弹性问题。使用三线性六面体元素进行离散化。应用共轭梯度求解器，通过不完全Cholesky分解（ICCG）预处理，用于求解具有稀疏系数矩阵的线性方程。引入Schwarz域分解以稳定并行预处理器。

GAMERA基于隐式低阶有限元方法解决复杂几何域中的3D非线性地震波传播问题。使用二阶四面体元素进行离散化，具有多网格和混合精度算术增强的自适应共轭梯度求解器。使用无矩阵矩阵-向量乘法方法，以减少内存传输和占用。

AMG2013、Milc和Lulesh来自Coral基准测试套件，我们只有x86_64优化版本。由于A64FX优化版本的这些代码不可用，我们仅使用OFP提供这些应用程序的结果。另一方面，LQCD和GAMERA是Fugaku开发项目的两个主要目标应用程序。这两个应用程序都有针对两个目标平台的高度优化版本，这些版本涉及大量的代码更改，但不同版本的应用程序解决了相同的科学问题。至于GeoFEM，虽然它有针对OFP的高度优化版本，但它也对在Fugaku上有效执行进行了一些微调。

OS噪音消除技术在Linux上的影响

本节提供了各种噪音消除技术对Linux的影响评估。我们强调，这些技术只应用于Fugaku，因为我们无法控制OFP的Linux环境，我们只是报告在该平台上捕获的结果。

使用FWQ评估噪音消除技术。使用的指标是每单位时间发生的噪音率（我们称之为噪音率）和最大噪音长度。噪音对批量同步应用程序的影响通常由最大噪音长度与同步间隔的比率主导，这一点过去通过模拟以及内核级噪音注入已经展示过。

我们评估的噪音消除技术如下：将守护进程绑定到辅助核心，将未绑定的kworker任务绑定到辅助核心，将blk-mq工作任务绑定到辅助核心，停止定期读取PMU计数器，以及抑制CPU全局TLB刷新指令。对于这些措施，我们捕获了关闭选定措施的FWQ结果，并将其与启用所有对策的基线进行比较。我们注意到，这些测量是在与主Fugaku系统相同的硬件和软件环境中的内部16节点A64FX系统上执行的。表2显示了最大噪音长度和相应的噪音率。

添加图片注释，不超过 140 字（可选）

计算方法如下。让我们用Ti表示第i次FWQ循环的执行时间，Tmax和Tmin分别表示所有循环中的最大值和最小值。最大噪音长度由Tmax - Tmin计算得出，噪音率由以下公式获得：

添加图片注释，不超过 140 字（可选）

此外，我们绘制了从FWQ输出计算出的噪音长度数据的时间序列。噪音长度Li计算为Ti - Tmin。图3a显示了启用所有对策时的噪音长度，而图3b和图3c显示了关闭个别对策时的噪音长度。X轴表示样本ID，即FWQ的第i次循环，Y轴绘制相应的Li。在没有噪音的理想情况下，样本ID大约每6ms增加一次。

从表格2和图表3中可以看出，每项措施都从系统中消除了大量抖动。确保操作系统守护进程被限制在辅助核心上的措施效果最为明显，消除了高达20毫秒的额外噪音。绑定kworkers、blk-mq和避免全局TLB无效化的措施影响范围在400微秒以内。

添加图片注释，不超过 140 字（可选）

然而，即使应用了所有噪音消除技术，系统中仍然存在一些操作系统噪音。我们发现剩余噪音的主要原因是名为sar的Linux工具，它定期监控系统活动，包括CPU、内存、I/O、网络、上下文切换和分页。这项服务在Fugaku上需要开启以用于操作目的。

为了更好地评估整个系统中的操作系统噪音，我们还捕获了扩展FWQ的数据。具体来说，我们将FWQ扩展为在任意数量的节点上运行（使用MPI）并同时在所有CPU核心上测量操作系统噪音。我们进行了大约6分钟的十次迭代测量，捕获了总共覆盖一小时的噪音概况。由于需要保存的原始数据量很大，我们仅在并行文件系统上保存了100个表现最差的计算节点（即，噪音持续时间最长的节点）的数据。使用捕获的所有数据，我们在图4中绘制了噪音数据的累积分布函数，比较了OFP和Fugaku，使用Linux和IHK/McKernel。

添加图片注释，不超过 140 字（可选）

在OFP上，我们使用了1,024个节点进行此实验，因为我们没有对整个机器的独占访问权。在Fugaku上，我们提供了以下三种配置的数据。对于McKernel，我们独占访问了24个机架（9,216个计算节点），并提供了该规模的数据。对于Linux，我们展示了全规模（158,976个计算节点）Fugaku系统上的测量结果，为了公平，我们也使用了与McKernel结果相同的24个机架。X轴表示FWQ迭代长度(ms)，Y轴表示累积分布函数（即，FWQ的尾部延迟）。

我们将OFP（图4a）和Fugaku（图4b）的结果的X轴缩放到相同的间隔，以便轻松比较两个系统的结果。第一个观察结果是OFP明显比Fugaku更嘈杂。特别是在OFP上，我们观察到在Linux下持续时间长达24毫秒的FWQ迭代（请注意，基准测试配置为捕获6.5毫秒的周期），而在Fugaku上最大的FWQ值约为10毫秒。关于Linux与IHK/McKernel，OFP上的McKernel提供了显著的噪音降低，McKernel上的最大值仍然小于7毫秒。然而，Fugaku上的情况更为复杂。虽然全规模Linux的数字明显比McKernel更嘈杂，但24个机架上的Linux实际上与McKernel的性能基本一致。

应用层面的结果

让我们关注应用层面的评估。如第上节所述，我们收集了使用OFP的三个Coral迷你应用的结果，以及另外三个主要来自Fugaku开发项目的应用，比较了Linux和IHK/McKernel在OFP和Fugaku上的表现。我们注意到，与FWQ测量类似，由于资源限制和稳定性问题，我们无法在Fugaku上收集全尺度测量结果，我们展示的是在多达24个机架上的测量结果。在两个平台上，我们都利用IHK/McKernel与作业提交系统的集成，并通过批处理作业系统运行测量，但我们注意到，在Fugaku上，我们确保对于每个节点计数，对于Linux和McKernel测量使用了完全相同的计算节点。我们还注意到，尽管我们展示了在两个平台上使用多达8k计算节点的数字，但由于Xeon Phi芯片上的硬件线程数量明显多于A64FX，实际上OFP结果代表了更高级别的并行性，OFP和Fugaku分别有2,097,152和393,216个硬件线程。

图5显示了Coral工作负载在OFP上的应用层面结果。在每个图表中，X轴表示计算节点的数量，Y轴表示性能。Linux数字（蓝色条）每个节点计数都标准化为1，McKernel性能（橙色条）表示与Linux的相对性能。我们展示相对性能而不是运行时间，因为一些应用程序报告了自定义指标。除非另有说明，我们至少运行了每个实验三次，并展示了平均性能，以及在有足够的数据时，误差条表示与平均值的偏差。

添加图片注释，不超过 140 字（可选）

正如图5所示，IHK/McKernel在所有Coral基准测试中都优于Linux。在AMG2013上，我们观察到高达约18%的性能提升，并且随着我们扩展到更大的节点计数，性能优势有增加的趋势。另一方面，我们观察到随着规模的增长，Milc和Lulesh的性能提升更为明显，McKernel在运行这些应用时分别达到了高达22%和近2倍的性能提升。正如我们在先前工作中讨论的，Lulesh的性能提升主要来自于Linux中的堆管理问题。

图6和图7总结了在OFP和Fugaku上LQCD、GeoFEM和GAMERA的应用层面结果。与Coral应用程序类似，OFP上的McKernel在这些应用中也一致优于Linux。图6显示了结果。尽管我们只有LQCD在多达2k节点的结果，我们观察到随着我们扩展到更大的节点计数，McKernel的性能提升增加，达到2k节点时接近25%。对于GeoFEM，我们有OFP的全尺度测量，McKernel在整体机器上优于Linux高达6%。令我们惊讶的是，即使在McKernel上，我们也发现测量结果有相当大的变化（由大误差条表示），尽管我们相信这可能与不同的测量在不同的节点上运行有关，这在较小的节点计数上尤其正确。关于GAMERA，我们有有限的数据点来显示所有尺度的误差条，我们决定只展示平均性能。如所见，McKernel在OFP超级计算机的一半规模上优于Linux超过25%。

添加图片注释，不超过 140 字（可选）

图7显示了Fugaku的结果。我们在Fugaku机器上观察到McKernel相对于Linux的性能提升要低得多，尽管可以说Fugaku上的8k计算节点在考虑整个系统的节点计数时仍然是相对较小的规模。LQCD在两个操作系统上几乎表现相同。对于GeoFEM，我们观察到在McKernel上运行时比Linux高出平均3%的性能提升，趋势表明即使我们进一步扩展，收益可能会保持不变。只有在GAMERA上，我们看到性能提升增加，达到在8k计算节点上运行时McKernel比Linux高出29%。我们进一步调查了GAMERA的结果，发现McKernel在应用程序的第一步（三步中的第一步）中表现明显更好，这可能与Linux上的一些初始化开销有关。如果应用程序运行更多的步骤，我们可能会看到McKernel的优势减少。不幸的是，我们有一个非常狭窄的窗口来精确定位性能差异的来源，但我们确实观察到McKernel由于LWK集成的Tofu驱动程序，RDMA注册更快，我们怀疑这是性能提升的主要贡献者之一。

高性能计算领域中操作系统的其他相关工作

在本节中，我们并不追求完整性，而是讨论了在高性能计算（HPC）操作系统领域最相关的研究工作。关于这一领域的更全面覆盖，请参见[13]。为HPC应用设计的轻量级内核（LWKs）可以追溯到20世纪90年代初。这些内核确保了低操作系统噪音、高可扩展性和对大规模科学应用的可预测性能。Catamount[29]是在生产环境中部署的第一个轻量级内核之一，它起源于桑迪亚国家实验室。IBM的BlueGene超级计算机系列也运行了一个名为计算节点内核（CNK）[20]的特定于HPC的轻量级内核。虽然Catamount完全是从头开始编写的，但CNK在很大程度上基于Linux代码，以便它能够更好地支持标准的UNIX特性。桑迪亚国家实验室最新的轻量级内核是Kitten[39]，与之前的轻量级内核相比，它独特之处在于提供了一个更完整的Linux兼容环境。还有一些从完整的Linux系统开始，通过引入修改以满足HPC需求的轻量级内核。Cray的Extreme Scale Linux[36, 41]、ZeptoOS[51]和在K计算机上部署的操作系统[28]遵循了这一路径。这些工作通常消除了守护进程，简化了调度器，并替换了内存管理系统。然而，Linux复杂的代码基础可能使得难以减轻所有不希望的影响，正如我们在本文中通过在Fugaku全尺度机器上捕获FWQ数字时所展示的那样。此外，对于修改Linux内核的项目来说，保持这些修改与快速发展的Linux源代码同步也是一项艰巨的任务。

随着多核处理器的出现，提出了轻量级多内核方法[18, 30, 37, 50]。多内核在CPU的不同核心上并行运行Linux和轻量级内核，以协作方式提供操作系统服务。FusedOS[38]是第一个提出这种方法的提案。其主要动机是解决系统和应用核心之间的CPU核心异构性问题。与McKernel相比，FusedOS在用户级别运行轻量级内核。FusedOS原型中的应用核心的内核代码只是一个stub，它将所有系统调用卸载到一个名为CL的用户级代理进程中。代理进程本身与IHK/McKernel中的类似，但在FusedOS中，整个轻量级内核都在CL进程内实现。FusedOS工作是第一个证明可以将Linux噪音完全隔离到Linux核心，并避免与在轻量级内核核心上运行的HPC应用的干扰。这种多内核方法的属性也是McKernel模型的驱动力之一。

在最近的多内核努力中，与我们项目最相似的是英特尔的mOS[19, 50]。mOS遵循了一条与Linux更紧密集成的路径，并且可以直接利用一些Linux内核基础设施。然而，这种方法的代价是Linux修改和在消除操作系统干扰方面的复杂性增加。

Argo[5]是一个针对类似工作流应用的E级操作系统项目。Argo的方法是使用操作系统和运行时专业化（通过增强的Linux容器）在计算节点上，这在某种程度上类似于Fugaku使用容器技术。Argo预计将使用基于Linux的ServiceOS来引导节点并运行管理服务。然后运行不同的容器实例，以满足应用程序或工作流片段的特定需求。

Hobbes[6]是DOE操作系统和运行时（OS/R）框架，用于极端规模系统。Hobbes设计的核心主题是改善对应用程序组合的支持。Hobbes利用虚拟化技术提供灵活性，以支持应用程序组件对不同节点级操作系统的需求。在其软件堆栈的底部，Hobbes运行Kitten[39]作为其轻量级内核，其上Palacios[31]作为虚拟机监视器。与IHK/McKernel相比，Hobbes在PCI设备级别分离了Linux和Kitten，这意味着在支持完整的POSIX API和将必要的设备驱动程序移植到Kitten方面存在一些困难。

结论以及未来的工作

HPC操作系统社区一直认为轻量级内核（LWKs）在极端规模的科学计算中有潜力超越Linux。然而，之前没有进行过大规模研究，将LWK与高度调整的Linux环境进行比较。在本文中，我们介绍了IHK/McKernel，一个为高性能计算设计的轻量级多内核操作系统。我们在两台大规模HPC系统上部署了McKernel，其中之一是Fugaku，本文撰写时是TOP500列表上最快的超级计算机。我们还描述了Fugaku的Linux软件环境以及我们为HPC扩展它所采取的具体措施。通过使用微基准测试和各种HPC应用程序进行严格的评估，我们得出结论，尽管我们的LWK可以在极端规模上超越Linux，但高度调整的Linux环境提供了接近LWK级别的性能，所有实验中平均接近4%。然而，根据我们在Fugaku的最新经验，跨操作系统更新（特别是在更新Linux内核时）维护Linux可扩展性是一项很难的工作，需要对Linux内部进行彻底研究。由于LWK不需要这样的研究，我们认为这是IHK/McKernel的一个明显优势。

在未来，我们将进一步寻求提高我们操作系统性能的机会，并打算在更广泛的应用程序上使用Fugaku的全部规模进行评估。我们还认为，随着专业处理核心（PE）变得越来越能干，并将最终允许运行特权模式代码，多内核操作系统结构在未来将发挥作用。最后，正如之前所展示的，多内核系统提供了出色的性能隔离，这在加速器装备的胖计算节点上的多租户部署中可能扮演重要角色，这也是我们未来考虑的研究方向。