我正在尝试了解 Linux 页面缓存以及它与内存 cgroups (v2) 的关系。我知道使用 cgroupsv1，内存 cgroups 可以是 isolated and have independent LRU lists （我假设 cgroupsv2 是相同的）。这一点以及 /-?\d+\.*\d+/ 有很多对 mm/vmscan.c 的引用并且有 a function 称为 mem_cgroups 的事实让我认为每个 cgroup 都有自己的页面缓存。 这个假设是真的吗？页面缓存中的所有页面都属于一个 cgroup 吗？
如果是真的，我知道页面缓存是由shrink_node_memcgs (here) 表示的。如何找出与给定 struct address_space 相关联的 cgroup？我是否只需要在 struct address_space 中找到第一页，然后从页面中找到 cgroup？
查了很多资料，原来的理解有几个问题。
首先，页面缓存是驻留在内存中的非连续页面的集合。很容易陷入将“页面缓存”视为单个连续内存块/页面（类似于硬件缓存）的陷阱，但页面缓存只是内存中一些可用页面的集合以备将来访问。
“页面缓存”中的这些页面甚至没有虚拟存储在一起。如在，内核 doesn't 将页面缓存中的所有页面保存在一个全局结构或列表中。相反，更好的思考方式是页面缓存实际上是内核中所有 LRU 列表的联合。
这一点以及 mm/vmscan.c 有很多对 mem_cgroups 的引用并且有一个名为 shrink_node_memcgs 的函数的事实让我觉得每个 cgroup 都有自己的页面缓存。
如前所述，每个 cgroup 都有自己的 LRU 列表。但是，每个 cgroup 都没有自己的页面缓存。但是，如果您整理所有 cgroup 中的所有 LRU，您将保留页面缓存的所有页面。
我知道页面缓存由结构地址空间表示
这是不正确的。 struct address_space 确实代表页面缓存中的一些页面，但它本身并不代表整个页面缓存。 struct address_space 实际上表示来自单个 inode（文件）或块设备的缓存页面（参见 host 结构中的 address_space member）。事实上，原始帖子中的 one 链接引用了这样一句话：“更好的名称 [for struct address_space] 可能是 page_cache_entity
或physical_pages_of_a_file。”（pg.327，第 16 章）
如何找出与给定结构地址空间相关联的 cgroup？
由于 address_space 对应于单个 inode（文件）而不是单个 cgroup，因此该结构中的所有页面都不会归入同一个 cgroup 并因此驻留在相同的 cgroup LRU 列表上。例如，假设 cgroup 1 中的一个进程读取一个大文件的开头，但是 cgroup 2 中的另一个进程读取该文件的结尾。每个进程访问的页面都来自相同的 inode 和 struct address_space，但其中一些页面将在 cgroup 1 的 LRU 列表中，而其他页面将在 cgroup 2 中。
因此不可能从 struct address_space 中找到 cgroup。相反，理论上，您可以遍历 struct address_space 页面，然后找到对应于每个单独页面 (page->mem_cgroup->css.cgroup) 的 cgroup。
请记住，由一个 cgroup 收费的页面可能仍会被不同 cgroup 中的另一个进程共享/访问。请参阅此处针对 v1 (Section 2.3) 和此处针对 v2 ("Memory Ownership") 的共享内存收费规则。
附录：
在我的研究过程中，我遇到了 this article，这让我感到困惑，并让我认为 address_space 与单个 cgroup 相关联。图 4.2 看起来好像 address_space 被埋在 mm_struct 中；并且由于 mm_struct 特定于一个进程，那么这个 address_space 也应该对应于一个进程，并且通过扩展，该进程的 cgroup。实际上，这个mm_struct对应的进程持有一个文件的文件描述符（用struct file表示），这个文件描述符指向文件inode及其对应的{{1} }.需要此 address_space 才能在“页面缓存”中专门从该文件中查找页面。