泰晓资讯·06月 / 第一期 / 2019 —— 资讯收集

[lzufalcon]

同学们好，这是 “泰晓资讯” 重新上线后第一次广泛收集 Linux 业界资讯，欢迎投递跟 Linux 内核、发行版、重要应用软件、行业峰会等相关的资讯素材，格式可参考：

• LKML: RISC-V Hypervisors

It’s a great pleasure to inform everyone that we have RISC-V hypervisor extension available for QEMU and along with it we also have Xvisor (a baremetal type-1 hypervisor) working on QEMU with RISC-V hypervisor extension. Currently, we are able to boot two Linux RV64 Guests on Xvisor RV64.

关键词：RISC-V，Xvisor, Qemu, Hypervisor。

RISC-V 作为完全开源的处理器架构，当前的发展如日中天，它的 Qemu 开发支持也在火热进行中。有了基础的 Qemu 模拟和上面的 Hypervisor 支持以后，RISC-V 的后续软硬件开发效率将大大提高，国内的厂商们速度跟进哈。

---

- [来源站点：内容标题](内容原文链接)

> 原文重要信息引用

**关键词**: 关键词1，关键词2

核心内容摘要，欢迎撰写特色评论。

[unicornx]

Transparent huge pages for filesystems

透明巨页（Transparent Huge Pages, 简称 THP）通过降低 TLB （Translation Lookaside Buffer）丢失的概率，可以极大地提升性能。在此基础上，Facebook 提出可以将频繁调用的函数指令存放在 huge pages 上从而利用该特性提升程序运行的效率。 具体做法是使用 Binary Optimization and Layout Tool (BOLT) 识别出程序中频繁调用的函数然后将它们收集起来放在可执行文件的一个特殊的节中（称为 hot section，大小为 8MB）。在运行时，应用程序会创建一个 8MB 大小的临时缓存，然后先将 hot section 的内容临时拷贝到这块内存区域。再为该内存区域创建一个对应的 huge page（通过匿名内存映射 mmap() + madvise() 的方式），huge page 创建好后，再将备份在缓存中的内容拷贝到该 huge page 中，最后再调用 mprotect() 将这块内存的权限设置为可执行（executable）。采用以上的方式，可以在不涉及修改 kernel 的前提下，获得 5~10% 的性能提升。但问题是这么一来该 THP 区域的符号地址以及 uprobe target 就乱掉了，因为 kernel 并不知道这块区域是程序代码段的一部分。假如在文件系统代码里面直接支持 THP，那就不用搞这么多复杂的小动作，直接用一个 madvise() 命令就可以达成以上目标。来自 facebook 的 Song Liu 目前正在致力于内核中这方面的改进，不过他目前的实现还比较简单，存在诸多限制。Song Liu 在 2019 年 的 LSFMM 大会上就这个问题向大家广泛征询意见，很多专业人事对此发表了各自的看法。更详细的内容请参考 "LWN 原文：Transparent huge pages for filesystems".

[unicornx]

[unicornx]openSUSE considers governance options: would the openSUSE project be better off under a separate foundation?

SUSE 与 openSUSE 社区之间的关系目前正在发生变化。一种可能性是考虑为 openSUSE 建立一个完全独立的基金会，这样它就可以获得更大的自主权并对自己的未来和运营拥有更大的控制。相关的讨论已持续数月，最早是在 4 月 2 日举行的 openSUSE 董事会会议上，后继又在 4 月 16 日 的会议上再次进行了讨论。在即将举行的 2019 年 openSUSE 大会上该问题也将成为董事会讨论的主要议题。有关 SUSE 本身的变化新闻也是持续不断，近期在私募风投基金 EQT 的支持下 SUSE 已经从 MicroFocus 公司脱离出来成为了一家独立的公司。openSUSE 董事会主席 Richard Brown 和 SUSE 领导都公开重申 SUSE 仍然会继续支持 openSUSE。目前最大的担忧是，从 SUSE 脱离后， openSUSE 是否能够不受其影响地持续自主运行。更多的详细报道，请阅读 "LWN 原文：openSUSE considers governance options"

[unicornx]

[unicornx]The rest of the 5.2 merge window: more changes for the next kernel release.

截至 Linus Torvalds 发布 5.2-rc1 版本并关闭了合并窗口，主线仓库中一共合入了 12064 个修改。下面简单摘取了一些主要的修改内容介绍给大家：

架构相关

• PowerPC 体系结构现在可以利用硬件上的支持来防止内核访问用户空间的数据。
• 32位 PowerPC 开始支持 KASAN。
• 合入了针对英特尔 “微架构数据采样（microarchitectural data sampling ）” 漏洞的缓解措施。有关问题的详细描述，请参阅内核文档中的此页面，以及此页面以获取缓解信息。

内核关键修改

• control-group v2 版本中更新了 freezer 机制（所谓 freeze 概念指的是停止运行一个 cgroup 以及该 cgroup 派生的 cgroup 中进程的操作）。和 v1 版本中的 freezer 实现方式不同，在停止一个进程运行后，现在的做法是将进程的状态设置为 stop，而不是原先的 uninterruptible sleep。这么做的好处是允许一个进程被停止运行后仍旧可以被 kill、trace 或者移动到另一个 group 中去。
• sysctl 增加了一个新的控制参数 vm.unprivileged_userfaultfd, 用于控制一个非特权（unprivileged ）用户是否可以使用 userfaultfd() 这个系统调用。为了和现有内核兼容，缺省的设置是允许非特权用户使用。
• 内核中新增了一个叫做 Pressure stall monitors 的工具，允许我们从用户空间获取实时的系统资源使用状况，特别是当前的内存使用情况。
• 日志跟踪（tracing）子系统导出了一个新的虚拟文件 tracing/error_log, 可以方便我们在出错时输出出错信息。
• /proc/slab_allocators 这个 slab 子系统导出的文件由于一直无法正常工作将被删除

更多详细的介绍请阅读 "LWN 原文：The rest of the 5.2 merge window"

[unicornx]

[unicornx]Telling the scheduler about thermal pressure: a patch set to help the scheduler do the right thing when thermal throttling happens.

即使使用散热器和风扇，系统的 CPU 也会过热。当发生这种情况时，为了降温，内核的 “热调节机制（thermal governor）” 将开始工作并限制 CPU 的最大工作频率。但是，调度器（scheduler）却不知道 CPU 当前的处理能力已经因为 “热调节机制” 的作用被降低了；结果调度器还会继续按原有方式为这个 CPU 安排运行任务，这显然超过了 CPU 当前的处理能力，这会导致性能的下降。最近，内核开发人员 Thara Gopinath 对这项工作做了一些研究并发布了一套补丁来试图解决这个问题。该解决方案添加了一些接口，可以让调度器以主动（调用）或者被动（回调）的方式获得有关温度变化的状态信息，以便它可以更好地分配任务，提高整体系统性能。社区看上去接受了该提议的想法。相关框架很可能在未来的某个版本中被合入内核主线。但在此之前，还有一些工作要做：譬如进一步完善算法的细节（譬如是否重用 PELT 代码等），当然还需要在不同的体系架构和系统上运行更多的基准测试。有兴趣的读者可以阅读 Gopinath 在 Linux Plumbers Conference 上发表的演讲的 幻灯片，该文档为这项工作的早期版本提供了额外的背景信息。更多详细的内容请阅读 "LWN 原文：Telling the scheduler about thermal pressure"

[unicornx]

[unicornx]Testing in the Yocto Project: how automated testing helped to catch and fix a kernel bug.

Yocto Project （简称 YP）的发起目的是提供一套包括了编译和维护定制化 Linux 发行版的套件。YP 对 Linux 发行版的编译流程完全是自动化的，整个流程覆盖了从编译生成编译器开始，到生成二进制文件，再到打包成软件包，以及最终生成镜像文件。YP 目前可以支持 4 大主流CPU 架构（ARM, MIPS, PowerPC, x86），包括 32 和 64 位模式，也可以支持多种 C 库，init 方案，和多种视窗系统（例如 no-X11, X11/GTK+, Wayland 等）。为了实现测试的自动化， YP 还引入了 QEMU，所有最终生成的发行版都可以在 QEMU 环境里启动运行。

在此基础上，YP 还提供了一套机制可以针对发行版中包含的很多开源项目执行自检，即运行这些开源项目中自带的自动测试用例， 这在 YP 中被称之为 “packaged test 或简称 ptests”。虽然 YP 很早之前就有 ptest，但最近才开始将其真正部署到自动测试系统里并定期执行。令人激动的是在最近 YP 升级到 Linux 5.0 内核的过程中，通过 ptests 这套机制，YP 成功地发现了一个真正的 kernel bug 并帮助社区及早定位并解决了这个问题。这说明让测试变得更加方便和更加自动，是非常有价值的事情。更多的详细介绍，请参考 “LWN 原文：Testing in the Yocto Project”

[unicornx]

简讯文摘

内核发布状态：

最新开发版本是 5.2-rc1，于 5 月 19 日发布，引自 Linus 的原话：“这个合并周期中没什么特别的令人激动的东西 ......”

其他稳定版本的更新状态：

• 5 月 17 日发布了 5.1.3，5.0.17，4.19.44，4.14.120，4.9.177，4.4.180
• 5 月 22 日发布了 5.1.4，5.0.18，4.19.45，4.14.121，4.9.178。

同样值得注意的是 3.18.140 的发布，这是官方维护的 3.18 系列的最后一个版本。虽然官方不再对其更新，但考虑到依赖于这个版本的用户群很大，所以这个系列的版本（包括一些其他的版本）依然会由 Android Open Source Project (AOSP) 负责维护。

沉痛哀悼 Martin Schwidefsky

内核邮件列表中带来了一个令人遗憾的消息 ，即长期的内核贡献者和子系统维护者 Martin Schwidefsky 不幸因事故丧生。以下为摘自邮件的原文：“Martin是 Linux 内核早期 s390 架构的最重要贡献者，后来成为该架构的备选维护者（backend maintainer）。他的技术专长和指导技巧都非常出色。Martin 以他积极的心态和坚强的意志而闻名。我们会永远想念他。”

更多有关 2019/5/23 这周 Linux 社区的简讯，请参考 “LWN Brief items”

[lzufalcon]

[falcon] Testing and the stable tree : how to make stable-tree really stable.

Levin 一直致力于让 Linux 内核的 Stable tree 更加的 Stable，他的两个关注方向是：”that fewer regressions are released“ 和 ”that all of the fixes get out there for users“。

第二点在 2018 年北美开源峰会上，Levin 介绍了 Machine learning and stable kernels，旨在自动的发现那些没有被人主动提交给 Stable release 的 patch，确保有更多的 fixes 能够同步到 Stable tree。

第一点则是如何确保这些 fixes 在人工 Review 之后有更充分的测试，这个 Topic 主要是聚焦这个问题。大家讨论到了用于 Filesystem 的 xfstests，用于 Storage 的 blktests，用于 Memory 的 MMTests。另外，大家也讨论到用哪些自动化的测试框架来跑这些测试，作者希望是 KernelCI，有听众提到为什么不是 O-Day automated testing，作者回复 O-Day 是 Semi Open 的不如完全开源的 KernelCI。后面大家有讨论一个 include/exclude list 的问题，主要原因是这些测试用例跑的时间可能很长或者本身并不能在任意内核版本任意配置选项上跑，所以需要维护一个子集，还要排除一些可能导致 false-positive 的特定 Test Case，LTP 是一个很典型的例子，它有数千个测试用例，但是不能照搬直接放到产品测试中，因为它本身会带来大量的误报（发现的Bug并不影响最终产品，但是可能需要耗费大量时间解决），需要设立 include/exclude list。

Levin 最后呼吁大家把好的 Test Case 贡献到 KernelCI，以便 Stable tree 可以跑更多更好的测试，从而让 Stable tree really stable。

[lzufalcon]

[falcon] Storage testing: how to use blktests

来自 Google 的 Ted Ts 同学最近在玩 NFS testing 和 blktests，NFS testing 主要用 xfstests。它用 blktests 找到了一个 ext4 的衰退，当然这个问题表现是 ext4，但是实际问题可能出在 SCSI multiqueue，block layer。他已经把这个用例集成进了他自己的自动化测试平台。他发现 blktests 还有待完善，比如说要跑所有的测试依赖打开 38 个内核模块，但是 blktests 并没有说明，他正准备把相关的 setup 工作贡献进 blktests，他建议更多的kernel developer 来跑 blktests，“it makes his life easier”。