内核持续集成（CKI）项目旨在防止错误进入 Linux 内核。

在 Linux 内核的持续集成测试 一文中，我介绍了 内核持续集成 Continuous Kernel Integration （CKI）项目及其使命：改变内核开发人员和维护人员的工作方式。本文深入探讨了该项目的某些技术方面，以及这所有的部分是如何组合在一起的。

从一次更改开始

内核中每一项令人兴奋的功能、改进和错误都始于开发人员提出的更改。这些更改出现在各个内核存储库的大量邮件列表中。一些存储库关注内核中的某些子系统，例如存储或网络，而其它存储库关注内核的更多方面。 当开发人员向内核提出更改或补丁集时，或者维护者在存储库本身中进行更改时，CKI 项目就会付诸行动。

CKI 项目维护的触发器用于监视这些补丁集并采取措施。诸如 Patchwork 之类的软件项目通过将多个补丁贡献整合为单个补丁系列，使此过程变得更加容易。补丁系列作为一个整体历经 CKI 系统，并可以针对该系列发布单个报告。

其他触发器可以监视存储库中的更改。当内核维护人员合并补丁集、还原补丁或创建新标签时，就会触发。测试这些关键的更改可确保开发人员始终具有坚实的基线，可以用作编写新补丁的基础。

所有这些更改都会进入 GitLab CI 管道，并历经多个阶段和多个系统。

准备构建

首先要准备好要编译的源代码。这需要克隆存储库、打上开发人员建议的补丁集，并生成内核配置文件。这些配置文件具有成千上万个用于打开或关闭功能的选项，并且配置文件在不同的系统体系结构之间差异非常大。 例如，一个相当标准的 x86\_64 系统在其配置文件中可能有很多可用选项，但是 s390x 系统（IBM zSeries 大型机）的选项可能要少得多。在该大型机上，某些选项可能有意义，但在消费类笔记本电脑上没有任何作用。

内核进一步转换为源代码工件。该工件包含整个存储库（已打上补丁）以及编译所需的所有内核配置文件。 上游内核会打包成压缩包，而 Red Hat 的内核会生成下一步所用的源代码 RPM 包。

成堆的编译

编译内核会将源代码转换为计算机可以启动和使用的代码。配置文件描述了要构建的内容，内核中的脚本描述了如何构建它，系统上的工具（例如 GCC 和 glibc）完成构建。此过程需要一段时间才能完成，但是 CKI 项目需要针对四种体系结构快速完成：aarch64（64 位 ARM）、ppc64le（POWER）、s390x（IBM zSeries）和 x86\_64。重要的是，我们必须快速编译内核，以便使工作任务不会积压，而开发人员可以及时收到反馈。

添加更多的 CPU 可以大大提高速度，但是每个系统都有其局限性。CKI 项目在 OpenShift 的部署环境中的容器内编译内核；尽管 OpenShift 可以实现高伸缩性，但在部署环境中的可用 CPU 仍然是数量有限的。CKI 团队分配了 20 个虚拟 CPU 来编译每个内核。涉及到四个体系结构，这就涨到了 80 个 CPU！

另一个速度的提高来自 ccache 工具。内核开发进展迅速，但是即使在多个发布版本之间，内核的大部分仍保持不变。ccache 工具进行编译期间会在磁盘上缓存已构建的对象（整个内核的一小部分）。稍后再进行另一个内核编译时，ccache 会查找以前看到的内核的未更改部分。ccache 会从磁盘中提取缓存的对象并重新使用它。这样可以加快编译速度并降低总体 CPU 使用率。现在，耗时 20 分钟编译的内核在不到几分钟的时间内就完成了。

测试时间

内核进入最后一步：在真实硬件上进行测试。每个内核都使用 Beaker 在其原生体系结构上启动，并且开始无数次的测试以发现问题。一些测试会寻找简单的问题，例如容器问题或启动时的错误消息。其他测试则深入到各种内核子系统中，以查找系统调用、内存分配和线程中的回归问题。

大型测试框架，例如 Linux Test Project（LTP），包含了大量测试，这些测试在内核中寻找麻烦的回归问题。其中一些回归问题可能会回滚关键的安全修复程序，并且进行测试以确保这些改进仍保留在内核中。

测试完成后，关键的一步仍然是：报告。内核开发人员和维护人员需要一份简明的报告，准确地告诉他们哪些有效、哪些无效以及如何获取更多信息。每个 CKI 报告都包含所用源代码、编译参数和测试输出的详细信息。该信息可帮助开发人员知道从哪里开始寻找解决问题的方法。此外，它还可以帮助维护人员在漏洞进入内核存储库之前知道何时需要保留补丁集以进行其他查看。

总结

CKI 项目团队通过向内核开发人员和维护人员提供及时、自动的反馈，努力防止错误进入 Linux 内核。这项工作通过发现导致内核错误、安全性问题和性能问题等易于找到的问题，使他们的工作更加轻松。

via: https://opensource.com/article/19/8/linux-kernel-testing

作者：Major Hayden 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

CKI 团队是如何防止 bug 被合并到 Linux 内核中。

Linux 内核的每个发布版本包含了来自 1,700 个开发者产生的 14,000 个变更集，很显然，这使得 Linux 内核快速迭代的同时也产生了巨大的复杂性问题。内核上 Bug 有小麻烦也有大问题，有时是系统崩溃，有时是数据丢失。

随着越来越多的项目对于持续集成（CI）的呼声，内核持续集成（CKI）小组秉承着一个任务目标：防止 Bug 被合并到内核当中。

Linux 测试问题

许多 Linux 发行版只在需要的时候对 Linux 内核进行测试。而这种测试往往只在版本发布时或者用户发现错误时进行。

有时候，出现玄学问题时，维护人员需要在包含了数万个补丁的变更中匆忙地寻找哪个补丁导致这个新的玄学 Bug。诊断 Bug 需要专业的硬件设备、一系列的触发器以及内核相关的专业知识。

CI 和 Linux

许多现代软件代码库都采用某种自动化 CI 测试机制，能够在提交进入代码存储库之前对其进行测试。这种自动化测试使得维护人员可以通过查看 CI 测试报告来发现软件质量问题以及大多数的错误。一些简单的项目，比如某个 Python 库，附带的大量工具使得整个检查过程更简单。

在任何测试之前都需要配置和编译 Linux。而这么做将耗费大量的时间和计算资源。此外，Linux 内核必需在虚拟机或者裸机上启动才能进行测试。而访问某些硬件架构需要额外的开销或者非常慢的仿真。因此，人们必须确定一组能够触发错误或者验证修复的测试集。

CKI 团队如何运作？

Red Hat 公司的 CKI 团队当前正追踪来自数个内部内核分支和上游的稳定内核分支树等内核分支的更改。我们关注每个代码库的两类关键事件：

1. 当维护人员合并 PR 或者补丁时，代码库变化后的最终结果。
2. 当开发人员通过拼凑或者稳定补丁队列发起变更合并时。

当这些事件发生时，自动化工具开始执行，GitLab CI 管道开始进行测试。一旦管道开始执行 linting) 脚本、合并每一个补丁，并为多种硬件架构编译内核，真正的测试便开始了。我们会在六分钟内完成四种硬件架构的内核编译工作，并且通常会在两个小时或更短的时间内将反馈提交到稳定邮件列表中。（自 2019 年 1 月起）每月执行超过 100,000 次内核测试，并完成了超过 11,000 个 GitLab 管道。

每个内核都会在本地硬件架构上启动，其中包含：

• aarch64：64 位 ARM，例如 Cavium（当前是 Marvell）ThunderX。
• ppc64/ppc64le：大端和小端的 IBM POWER 系统。
• s390x：IBM Zseries 大型机
• x86\_64：Intel 和 AMD 工作站、笔记本和服务器。

这些内核上运行了包括 Linux 测试项目（LTP）在内的多个测试，其中包括使用常用测试工具的大量测试。我们 CKI 团队开源了超过 44 个测试并将继续开源更多测试。

参与其中

上游的内核测试工作日渐增多。包括 Google、Intel、Linaro 和 Sony 在内的许多公司为各种内核提供了测试输出。每一项工作都专注于为上游内核以及每个公司的客户群带来价值。

如果你或者你的公司想要参与这一工作，请参加在 9 月份在葡萄牙里斯本举办的 Linux Plumbers Conference 2019。在会议结束后的两天加入我们的 Kernel CI hackfest 活动，并推动快速内核测试的发展。

更多详细信息，请见我在 Texas Linux Fest 2019 上的演讲。

via: https://opensource.com/article/19/6/continuous-kernel-integration-linux

作者：Major Hayden 选题：lujun9972 译者：LazyWolfLin 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在上周，我们对 KVM 和 Xen 近几年里在性能上的改进进行了一些有趣的探讨后，我打算自己做一些这方面的小研究。我能找到的最新的资料，是来自2013年 Phoronix Haswell 性能评测上的基准测试。当然，还有其它一些2011年的评测，不过由于 Xen 被收录进 Kernel 3.0，它们都已被热烈地讨论过。

2011年的测试提供了许多很好的基准报表，在三年后的现在，我尽最大努力把它们列出的属性重新测试一遍。但我删减了其中两三个基准测试，原因是它们在未经特定优化的配置后跑出来的数据不是很好，或者它们需要跑很长时间才能得到结果。

测试环境

测试环境由两台一模一样的超微服务器组成，分别都配备一颗Intel 至强 E3-1220（4核，3.10GHz），24G 金士顿 DDR3 内存，4块西数 RE-3 160G 磁盘（组成 RAID10 阵列）。另外 BIOS 也是一模一样。

所有测试项目（即实体机和虚拟机）都在 Fedora 20 （开 SELinux）上进行，并且测试过程中几乎没有运行的不相关的服务。这里列一下相关服务的版本：

• Kernel: 3.14.8
• For KVM: qemu-kvm 1.6.2
• For Xen: xen 4.3.2

根文件系统都是使用默认配置的 XFS。虚拟机使用 virt-manager 来创建（virt-mamager 也使用默认配置）。虚拟磁盘使用 raw 镜像，容量为 8GB，虚拟4颗 CPU。Xen 虚拟机使用 PVHVM 建立虚拟磁盘。

附加说明

也许有人会考虑到 Fedora 是红帽公司所有，红帽一直在维护 KVM，而 Xen 则自从在2009年红帽重新选择 KVM 作为虚拟化产品后，再没得到这个公司的重要改进。我将这个因素排除在了测试所考虑的范围之外，不过仍然可以在心里稍微注意一下。

并且，资源竞争产生的影响也有被严格控制并最小化。在大多数虚拟服务器上，你可以跑多个虚拟机，而这些虚拟机会争用 CPU 时间片、磁盘 IO、网络带宽等等资源。在本测试中也不考虑这些因素。一台虚拟机抢到资源少，性能就差，而另一台抢得多，性能就好（LCTT译注：它们的性能总和，就可 以大致当作是 KVM 或 Xen 的性能了）。

本测试运行在 Intel 的 CPU 上。如果使用的是 AMD 或 ARM，可能有些数据会不一样。

结果

本测试使用裸机作为虚拟服务测试的基准设备。在不跑虚拟机的情况下，两台裸机的性能偏差不会大于0.51%

在几乎所有测试中，KVM 的性能相比宿主机而言下降了1.5%以内，只有两项测试例外。第一个是 7-zip 压缩，比宿主机慢了 2.79%。第二个就奇怪了，我们搭了一个邮件服务器，用 PostMark 测试其性能，结果表明 KVM 竟比宿主机快了4.11%。然后我在两台服务器中重新跑了几遍 PostMark 测试，结果性能差异基本不变，浮动都在最初测试结果的1%以内。由于我对 virtio 的内部机制没有很深的理解，我只能在以后再对这个怪现象进行进一步了解。

Xen 的性能相对宿主机而言差异就比较大了。有3项测试性能下降在2.5%以内，剩下的性能下降率都是 KVM 的2～4倍。PostMark 测试的性能比 KVM 慢了14.41%，这结果令我大吃一惊。重新跑了下测试，性能差还是几乎不变，浮动都在最初结果的2%以内。KVM 表现最好的 CPU 测试：MAFFT 对齐测试，是 Xen 表现倒数第二差的。

现在奉上一个简短得总结表：

如果需要完整数据，请查看Goole Docs 电子表格。

结论

基于上面的测试环境，KVM 的性能损耗几乎都在2％以内，Xen 则在十多项测试中有3项损耗在2.5％以内，而其他几项损耗都在5~7%之间。虽然 KVM 在 PostMark 测试中性能表现优异，但这是众多测试中仅有的一项 I/O 测试，如果想证明 KVM 确实在 I/O 处理方面很强悍，就需要更多测试。

对我来说，我想要深入了解一下 KVM 和 Xen 在 I/O 方面的处理，以及它们之间为什么会有这么大的差别。我也许还会跑一些有竞争的测试，来看看虚拟机在有压力的条件下是否真的能比宿主机表现得更出色。

我鼓励读者通过使用Phoronix 测试套件来进行一些基准测试，你们可以找到一些能模仿你们工作环境的用例。如果你的工作环境是低 CPU 高 I/O，你可以找找套件里面的 I/O 压力测试。另一方面，如果你的工作是音频、视频转码，你可以试试套件里面的 x264 或 mp3 测试。

更新：Chris Behrens 指出， 我忘了提到 Xen 虚拟机类型了。这里补充下，我使用的是 PVHVM 模型（LCTT译注：目前支持的模型包括 PV、HVM 和 PVHVM），因为在 Xen 4.3 中这个选拥有最好的性能。另外需要注意的是在 Xen 4.4 中可以使用 PVH，但是在 Fedora 20 中还没有使用 Xen 4.4。

via: http://major.io/2014/06/22/performance-benchmarks-kvm-vs-xen/

译者：bazz2 校对：ReiNoir

本文由 LCTT 原创翻译，Linux中国 荣誉推出