MGLRU 靠 look-around 抓住热页
回收与老化之间的反馈环
shrink_folio_list()
走 rmap 反查
发现 young PTE
lru_gen_look_around()
顺势扫同一 PMD 下相邻 PTE
利用空间局部性
命中的热 folio
晋升到新 generation
这一趟扫描有成本
值不值得下轮再扫，要看 young 计数
扫不扫，由 young 计数裁决
look-around 有成本，不能每轮都扫
循环计数
窗口内扫过的 PTE 总数
与其中 young 的数量
suitable_to_scan()
平均每条 cacheline 至少 1 个 young PTE
通过才继续
通过：把这张 PTE 表的 PMD 加进 bloom filter
下轮 aging 的页表遍历复查它
young 少计，这个判定就可能翻
现状 · PTE 批量化后按 nr 计
nr 是 folio 在这张 PTE 表里连续映射的 PTE 数
循环里遇到 young folio
young += nr
按批量大小累计
nr
连续映射的 PTE 数
同一张 PTE 表内
循环里每个 young folio 都按批量计
除了触发 look-around 的那一个
问题 · 触发的 folio 只按 1 计
它在函数入口已经被清过 accessed 位
入口：清 accessed 位
循环不会再数它
贡献只能由初值给出
int young = 1
large folio 少计 nr-1
没跟批量口径走
少计让 suitable_to_scan() 误判
热 PMD 进不了 bloom filter，下轮 aging 不复查
仍有热 folio 的 PMD 被漏过
热 folio 可能被误回收
方案 · 初值从 1 改成 nr
触发 folio 与循环里的其他 folio 同一口径
- int young = 1;
+ int young = nr;
一行之差
同一口径
循环里 young += nr
触发 folio 也给 nr
large folio 不再少计 nr-1
初值不再是固定的 1
批量大小就是它的贡献
边界 · 为什么可以直接给 nr
刻意高估，不是实测
test_and_clear_young_ptes_notify()
只报告 nr 个 PTE 中是否有 young
不报具体几个
mm 核心按 folio 粒度
跟踪 accessed 状态
逐页计数既不可得也无意义
唯一消费者：suitable_to_scan()
它喂的 bloom filter 容忍误差
高估是安全方向
至多让访问少的 PMD 多扫一轮
低估才会漏掉仍热的 PMD，造成误回收
预期收益 · 作者未提供性能数据
以下均为代码逻辑推断，不是实测
large folio 的 young 贡献与全窗口同一口径
mTHP 负载下 aging 准确性恢复
仍有热 folio 的 PMD 正常进 bloom filter
接受复查，减少误回收
高估方向安全
代价至多 PMD 多扫一轮
空格
播放/暂停
←
→
逐动作
R
重播
⚠
1x