17611538698
developer@21cto.com

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

作者 Admin 分类 资讯 09月25日

ximg_54c83a8155ff3.jpg.pagespeed_.gp_jp_jw_pj_js_rj_rp_rw_ri_cp_md_.ic_.ZlkzO3HSaY_.jpg


  
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 许可协议。

 

评论