内核如何在磁盘缓存和交换之间做出决定？

释放物理内存页的整个任务的名称是回收，它涵盖了许多任务。回收主要由页面分配驱动，具有不同程度的紧迫性。在卸载的系统上，页面分配可以毫不费力地得到满足，并且不会触发任何回收。在中等负载的系统上，仍然可以立即满足页面分配，但它们也会导致kswapd被唤醒以执行后台回收。在无法立即满足页面分配的已加载系统上，同步执行回收。

可回收页面是存储可以在其他地方找到或可用的内容的页面。这就是典型的平衡行为发挥作用的地方：内容也在文件中（或应该以文件结尾）的内存，v. 内容不在的内存（并且需要换出）。前者存储在页面缓存中，后者不存储，这就是为什么平衡解释通常谈论页面缓存与交换。

在内核中的一个位置确定优先于另一个的决定，get_scan_count由 中的设置控制struct scan_control。该函数的目的描述如下：

确定扫描匿名和文件 LRU 列表的积极程度。每组 LRU 列表的相对值是通过查看我们确实旋转回活动列表而不是驱逐的扫描页面的比例来确定的。

对于名为 的函数get_...，这可能令人惊讶，它不使用返回值；相反，它填充unsigned long *nr指针指向的数组，其中四个条目对应于匿名非活动页面（未支持，最近未使用的页面），匿名活动页面（未支持，最近使用的页面），文件不活动页面（页面缓存中最近未使用的页面）和文件活动页面（页面缓存中最近使用的页面）。

get_scan_count首先从 检索适当的“swappiness”值mem_cgroup_swappiness。如果当前内存 cgroup 是已启用的非 root v1 cgroup，则使用其 swappiness 设置；否则，就是臭名昭著的/proc/sys/vm/swappiness。两种设置的目的相同；他们告诉内核

带回换出的匿名页面与重新加载文件系统页面的相对 IO 成本

在它实际使用这个值之前，get_scan_count确定它应该应用的整体策略：

• 如果没有交换，或者在当前上下文中无法回收匿名页面，它将只处理文件支持的页面；
• 如果内存 cgroup 完全禁用交换，它将只处理文件支持的页面；
• 如果没有禁用swappiness（设置为0），并且系统几乎没有内存，它将平等地处理所有页面；
• 如果系统几乎没有文件页面，它将只查找匿名页面；
• 如果有足够的非活动页面缓存，它将只处理文件支持的页面；
• 在所有其他情况下，它会根据相应的 I/O 成本调整赋予各种 LRU 的“权重”。

一旦确定了策略，它就会遍历所有可驱逐的 LRU（按顺序为非活动匿名、活动匿名、非活动文件支持、活动文件支持）以确定应该扫描每个 LRU 的多少页；我将忽略 v1 cgroups：

• 如果策略是“平等地追踪所有页面”，则所有 LRU 中的所有页面都可能被扫描，直到由scan_control的priority移位因子确定的大小；
• 如果策略是“仅查找文件支持的页面”或“仅查找匿名页面”，则相应 LRU 中的所有页面都是候选页面（再次，移位priority），其他 LRU 中没有；
• 否则，这些值会根据 swappiness 进行调整。

实际的页面扫描由 驱动shrink_lruvec，它使用上面确定的扫描长度，并反复收缩LRU，直到达到目标（以各种方式调整目标）。完成此操作后，将重新平衡活动/非活动 LRU。

回到你的问题：

• 页面缓存和内存映射文件被同等对待；
• 页面回收并非纯粹基于上次访问（我没有解释 LRU 是如何使用的，或者重新平衡是如何工作的；请阅读Mel Gorman 的了解 Linux 虚拟内存管理器中的相应章节了解详细信息）；
• 内核没有平等地使用它们；根据情况，它们的优先级不同，并且可以通过许多控件（swappiness、cgroups、低水位阈值...）进行配置。

交换优先级仅确定页面在决定将其换出后的去向。（顺便说一下，swappiness上面的文档和解释应该清楚地表明，I/O 成本没有足够的粒度来很好地处理混合 ZRAM/磁盘交换设置......）

还有很多要解释的，包括如何scan_control设置，但我怀疑这已经太长了！如果您想跟踪回收成本，您可以在任务延迟会计中看到它（另请参阅struct taskstats）。