【翻译】清理濒临死亡的对照组

CSDN-Ada助手

于 2023-08-26 16:21:14 发布

阅读量2.5k

点赞数 4

分类专栏：翻译

翻译专栏收录该内容

296 篇文章 16 订阅

订阅专栏

本文由 LWN 订阅者提供

LWN.net 的订阅者成就了这篇文章以及与之相关的一切。如果您喜欢我们的内容，请购买订阅，让下一组文章成为可能。

作者： Jonathan Corbet
2019年5月7日

LSFMM

控制组是管理系统资源使用情况的有用机制，但当控制组本身成为资源问题时会发生什么？在 2019 Linux 存储、文件系统和内存管理峰会的一次全体会议上，Roman Gushchin 描述了他在删除控制组时遇到的问题，这些控制组在真正消失之前会慢慢消失。其中一些问题已经解决，但问题还没有真正解决。

控制组是使用虚拟文件系统管理的；只需删除代表该组的目录，就可以删除该组。但事实上，Gushchin 说，虽然删除控制组的目录会从用户空间隐藏该组，但该组会继续存在于内核中，直到所有对它的引用都消失为止。当它继续存在时，就会继续消耗资源。

对于内存控制组来说，这个问题尤为严重，因为该组的每个页面都有一个引用。因此，一个给定的控制组要真正被删除，必须先回收所有被计费的页面，而这可能需要很长时间。如果某些页面仍在使用，它们可能会无限期地避免被回收。此外，各种错误也会导致已删除的组继续存在。所有这些都导致被删除的控制组在系统中徘徊和纠缠；他在运行一周后发现了 1500 个这样的控制组。

他说，这个问题的后果并不严重，但仍然 "不太好"。每个控制组存在时会消耗大约 200KB 内存，当成千上万个控制组等待死亡时，内存消耗就会开始增加。所有这些组都增加了在内核中遍历控制组层次结构的复杂性（和成本）。内存使用也会影响内存管理会计。

删除控制组的某些原因比其他原因更容易处理。例如，在处理用户页面时存在一个四舍五入错误，导致最后一个页面没有被回收。这个错误在两个版本的控制组子系统中都出现过，现已得到修复。另一个问题与内核堆栈的核算有关；它是在 2016 年改用虚拟映射堆栈时引入的。这些堆栈由首次分配它们的进程（及其组）计费；当堆栈被新进程重复使用时，计费不会更新。这个问题也已得到修复。

一个尚未解决的问题与从板块分配器获取的内核内存有关。许多缓存对象（如 dentry 结构）都是从板块分配器中获取并计入相应的控制组；在真正删除控制组之前，它们也必须被清理。但在内存压力不大的情况下，收缩器的运行并不积极，这些对象可能会存在很长时间。 Gushchin 曾尝试使用一个补丁来施加额外的压力，但它导致了 XFS 文件系统的性能下降，随后被重新启用。因此，他现在正在研究一种不同的方法：在移除控制组时重新分配板块缓存。有一套补丁正在审核中，希望这个问题能在不久的将来得到解决。

通过这些修复，他观察到的问题已经得到解决，但还有其他潜在问题。使用vmalloc()获取的页面和每 CPU 页面是可能出现问题的领域之一。不过总的来说，他认为很容易创建对控制组的隐藏引用，这可能会阻碍控制组的移除；这也是可能出现回归的一个领域。

在会议结束时，Michal Hocko 说，问题的部分原因只是用来表示内存控制组的结构的大小。也许可以把结构一分为二，在删除控制组时只保留核心部分，这样情况会好一些。但约翰内斯-韦纳回答说，现在只有内存压力在削减这些被删除的组；如果把它们变小，它们只会堆积得更深。因此，虽然这个问题的某些表现形式已经得到了解决，但即将消失的控制组问题就像控制组本身一样，还将存在一段时间。