LWN: Linux desktop环境下的资源管理

  
Resource management for the desktop

By Jonathan Corbet
August 27, 2020
LPC
原文来自：https://lwn.net/Articles/829567/
DeepL assisted translation.

自从我们有桌面系统（desktop system）以来，就一直在关注 desktop 系统的响应是否迅速，开发人员一直在努力改善这方面的情况。多年来，Linux 已经拥有了一些可以用来改善桌面性能问题的功能——特别是 control group，但这些功能的一般都会在提供出来之后过些时间才能真正应用起来。在 2020 年的 Linux Plumbers Conference 上，Benjamin Berg 概述了 Linux 桌面项目正在进行的一些工作，以将近期新增的内核功能应用起来。

他首先介绍说，他关注的重点是桌面系统的资源管理，其中的资源是 CPU time、memory 和 I/O bandwidth。目前的系统会让应用程序自行争抢这些资源，很少有监督协调。其实可以通过调整 nice（CPU 优先级）级别来偏向某些应用程序，但这种改变会在进程级别上生效。大多数情况下，Linux 桌面系统都是在进程级进行管理的，这对我们碰到的问题来说是不够的。

通过利用 cgroup 提供的功能，应该可以做得更好。不再对 process 一视同仁，而是对 user 或 application 平等对待，不管它们运行的进程数量有多少。cgroup 还可以帮助使桌面更加灵敏；desktop manager 桌面管理器可以利用它们来根据各个 service 的重要性、或者某个用户在此刻是否活跃、或者某个的应用程序是否具有焦点（focus）等因素来进行决策。

现在虽然是 2020 年了，但像内存内容颠簸（thrashing）和 out-of-memory（OOM）处理等问题仍然困扰着桌面系统。最近已经有一些工作来改善这种情况了，例如，Fedora 在 Fedora 32 版本中采用了 earlyoom 守护进程。Earlyoom 是 “memory-available”这种方法的一个例子，其核心思想是确保系统始终有足够的内存可用，以便在 cache 中保持住 workload 所需的文件。这样就可以防止系统将用户当前正在运行的可执行文件 page out 出去（也就避免了不必要的 fault in）。memory-available 这种方法的优点是可以使用当前的信息，有需要的话，它们可以每秒多次轮询有多少内存可用。

另一种方法是使用相对较新的内核能提供的 pressure-stall 信息。像 low-memory-monitor、nohang 和 oomd 这样的工具就使用这些信息来管理系统内存。Berg 说，从某种程度上来说，这是一种比较好的方法，pressure-stall 信息是一种比较可靠的方法，可以判断系统是否在做 thrashing。但它的速度也相对较慢，每十秒左右计算一次,这对桌面场景来说太慢了。

一些发行版也在尝试更快地进行 swapping，以此来提高内存的可用性；比如交换到 zram 设备可以提高系统的响应速度。他说，在这个领域有很多方法在尝试中。

但有一个根本性的问题：这些方法都不能有效地保护图形会话（graphical sessions），也无法确保它们拥有所需的资源。真正的目标是确保像图形界面里的 shell 进程这样的关键进程在任何时候都是可以确保响应的。必须识别出有问题的应用程序，并将其隔离或杀死。在全系统范围内管理可用内存并不能做到这一点。
 
Using control groups

不过，cgroup 可以。它们正是为这种进程遏制和控制而设计的。通过使用内存、CPU 和 I/O-带宽 cgroup，桌面管理器就应该能够遏制 thrashing 现象并确保重要进程的资源需求得到满足。

这个想法引出了下一个问题：应该如何管理这些 cgroup，以创建所需的进程隔离级别？目前看来，systemd 通过对 cgroup 的管理，提供了所需的功能。所以 GNOME 项目，以及其他桌面环境也开始使用它。之所以说 “开始”，是因为许多所需的功能都是在去年才出现的。

要达到这个目标，需要在 D-Bus 子系统中建立一个 per-user 的 session bus。为了正确检测出 session，我们做了很多 fix。需要将 GNOME 工具移植到 systemd API 中。像 gnome-terminal 这样的工具已经学会了为每个标签页创建一个新的 scope（作用域），提供恰当的进程隔离。KDE 项目等也在致力于 systemd 的集成。

一套用于管理 systemd 内桌面会话的规范正在开发中（https://systemd.io/DESKTOP_ENVIRONMENTS/ ）。用户会话被分成三个独立的 cgroup：

• session.slice 包含基本的会话进程，比如桌面 shell。
• app.slice 包含普通的应用程序。
• background.slice 包含 “不那么急迫的东西”，比如索引进程或备份操作。

 用户运行的所有程序都会被归入其中的某一个组。每个应用程序都在上述其中一个组下得到自己的 cgroup；然后将应用程序 ID 写入到相关的 systemd unit 名中。

这种安排使得 cgroup 的属性可以在 per-slice 或 per-application 的基础上进行单独修改。换句话说，现在可以以每个应用程序特有的方式来控制资源的可用性。KDE 利用这个特性实现了一个新的任务管理器，它显示的是应用程序而不是进程。一个应用程序可能会运行许多进程，但这不是用户通常关心的细节，进程的数量不应该影响应用程序的可用资源。目前人们正在为 GNOME 创建一个类似的工具，使每个应用程序的资源使用情况信息更容易获得。

不过这项工作还没有完成。还有更多的工具需要迁移到 systemd API 上。例如，xdg-autostart 应用程序仍然没有得到正确的处理。应用程序经常会启动其他应用程序。想想当用户点击一个链接时，一个聊天应用程序会启动一个浏览器。浏览器应该被归入自己的组，而不是和聊天程序归为一组。应用程序 “现在只是在调用其他东西”；它们需要开始进行恰当的调用，以确保能够正确进行分组。他说，KDE 现在已经有了一个可行的 API，GNOME 的 glib 库也在更新中。

目前，向 systemd 的迁移还没有完成，应用程序仍然经常会被归入错误的 cgroup。但它 “在大多数情况下都可以工作”，已经相当有用了。
 
uresourced

把应用程序加入正确的 cgroup 是朝着正确方向迈出的第一步，它确保应用程序相互竞争，而不是进程竞争。但这还不足以创建一个真正的响应度高的桌面，这需要调整这些 cgroup 的可用资源，以实施所需的策略。为此，他一直在研究一个名为 uresourced 的资源管理器，它可以使能（enable）和管理应用程序的 CPU、内存和 I/O 控制器。

例如，uresourced 会跟踪谁是活跃用户，并为该用户分配 250MB 的内存（或可用总量的 10%，以较低者为准）；此配额会分配给了 session.slice 组，以便它可以用于最重要的应用程序。活跃的用户也获得了更大份额的可用 CPU 时间和 I/O 带宽。因此，应用程序（而不是进程）现在正在竞争 CPU，而活跃用户获得了更大的份额。无论系统的工作负载如何，核心会话进程都应该受到保护，不被打乱。不过他坦言，他还没有找到测试这种行为的有效方法。

这项工作还没有完成，其中，I/O controller 还没有完全配置好。Systemd 还没有实现这些必要的选项好进行相应地配置，例如，它不能使用 io.cost（以前是 io.weight）controller。当例如 Fedora 等发行版在使用逻辑卷管理器(LVM，logical volume manager)时，也会出现一些复杂的问题。为这个任务添加一个新的守护进程的话似乎也有点儿过了。Berg 预计 uresourced 最终会被吸收到其他东西中。他说，理论上来说应该合并到 systemd-logind 里面，但它目前还不是很容易加进去。

目前，uresourced 将作为 Fedora 33 版本的一部分发布；Fedora 32 用户也可以通过单独安装来试用它。

Berg 最后提出了几个遗留问题，首先是 systemd-oomd(oomd 与 systemd 的集成)是否能在桌面系统上很好地工作。他还没有尝试过，但它应该能够检测到有问题的 workload。真正需要决策的，是当这种情况发生时如何应对。可选方案包括冻结违规进程并询问用户该怎么做、简单地杀死它、或者尝试用 cgroup 参数主动控制它。目前，除了试一试看看效果如何外，没有什么可做的。

他想知道用户会话的隔离是否足够。使用 CPU、内存和 I/O-带宽 controller 应该足以完成这项工作。不过他担心，如果 I/O controller 有些异常的话，最终可能会使桌面瘫痪。他又提到了 LVM 使用时出现的问题，以及无法使用 io.cost controller。他说，内核提供的功能很好，但可能还无法用在桌面环境中。

还可以做些什么呢？一个选项就是对目前以桌面为重点的应用进行优先排序。他说，这应该很简单，只要找到合适的 cgroup，并据此设置优先级即可。也许还可以做一些节省功耗的工作，例如找到并冻结那些进行过多唤醒的任务。

在这方面显然还有很多工作要做，但似乎正在取得进展。在不久的将来，桌面系统将变得更加灵敏。

本次会议的幻灯片[PDF]可供查阅。（https://linuxplumbersconf.org/ … t.pdf）

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。