MGLRU memcg 轮转、ParkEvent 对齐与 trait solver 快路径

本期检索说明

先读取 content/collections/deep-radar 截至 2026-10-13 的全部原文链接，并按 URL、标题与实现机制去重。最近 24 小时内，OpenJDK ParkEvent 与 rustc 新 trait solver 两项改动同时具备实测、源码和原理证据；为避免连续偏向 JVM/Rust，再按规则回溯最近 7 天，收录 10 月 13 日凌晨发布的 Linux MGLRU memcg 轮转补丁。本期 3 篇均未在既往报告中出现。

Kotlin 近期候选以正确性修复和代码清理为主，缺少可复核 benchmark；Zig 没有找到三类证据同时齐备的新材料。三项入选工作截稿时都仍在评审：Linux 数据统计的是持续返回 EAGAIN 的 reclaim 尝试次数，不是回收字节数；OpenJDK 没有发现性能回退，但主要收益是 native memory；rustc 仍有 RSS、cycles 与 artifact size 负向样本。以下结论保留这些边界，不把开放 PR 写成已发布特性。

01 · Linux：把 MGLRU memcg 轮转从锁内线性扫描降为 O(1)

原文与日期： Max Kellermann，2026-10-13 04:54（中原标准时间）；LKML 补丁组邮件镜像、同日 LKML 索引 与 Linux MGLRU 官方文档。

为什么值得读： MGLRU 用 memcg_lru 把 memory cgroup 按代和节点组织起来，回收器会在这些分桶间轮转 memcg。拥有数万 cgroup 的机器出现 soft lockup 与 RCU stall，根因并不是复杂的页面扫描，而是一个看似普通的链表尾插：lru_gen_rotate_memcg() 在持有每节点 memcg_lru.lock 且关闭中断时，为找到目标分桶尾部遍历整条链。并发 reclaim worker 越多、cgroup 越多，锁内 O(n) 工作和自旋等待越严重。这个案例很适合迁移到调度队列、GC region 集合和运行时分代列表：数据结构复杂度必须连同锁域和抢占状态一起审计。

核心技术结论： 前三块补丁为每个分桶缓存尾节点，并增加 hlist_nulls_add_behind_rcu()，把插入从扫描链表变为常数时间；第四块补丁发现 memcg 已位于当前 young generation 的默认 segment 时跳过冗余轮转；第五块在 memcg reclaim 尝试、分桶切换和 retry 边界补充 reschedule 点。前四块减少锁内工作，第五块改善长循环的可调度性，解决的是两个不同层次的问题。

最有价值的实验、源码与 benchmark 细节： 补丁在 Linux 6.18、12 核 Xeon 5118 上预建 1,500 个 memory cgroup，8 个 worker 连续向根 cgroup 的 memory.reclaim 写入 1024M swappiness=0，持续 60 秒；每次请求返回后才发下一次。所有请求都返回 EAGAIN，因此表中吞吐表示“完成的 reclaim 尝试”，不是成功回收的容量。

仅尾指针改造就提升约 9.52×；再跳过冗余轮转，相对前三块又提升 36.4%；完整系列相对基线为 12.68×，平均延迟下降 92.1%。第五块加入 reschedule 后吞吐略低于 1–4，且作者没有单独给出调度延迟数据，因此它不能被描述成吞吐优化。源码层面最关键的是 mm/vmscan.c 不再在锁内寻找链尾，include/linux/mmzone.h 为分桶保存 tail，include/linux/rculist_nulls.h 提供 RCU-safe 的 behind insertion。

适合的工程师背景： 熟悉 Linux reclaim、memcg、MGLRU/RCU，或正在诊断高基数租户场景中锁竞争与不可抢占区间的内核工程师。

预计阅读收益： 约 40–55 分钟；能学会把算法复杂度、锁持有时间、中断状态和调度点放进同一条性能因果链，并辨别吞吐数据实际测量的工作量。

02 · OpenJDK：移除不再承担锁状态编码的 ParkEvent 对齐

原文与日期： Fredrik Blomberg，2026-10-13 21:49（中原标准时间）；OpenJDK PR #33344、完整源码 diff 与 JBS JDK-8393648。

为什么值得读： ParkEvent 是 HotSpot 线程阻塞/唤醒路径的底层对象。旧 Mutex/Mux 实现曾把锁状态编码进指针低字节，因此对象地址必须 256 字节对齐；JDK-8210832 与 JDK-8225631 已移除这套编码，分配器却继续为每个对象额外申请并手工对齐。每个 Java 线程持有两个 ParkEvent，于是过时约束在高线程数应用中变成稳定的 native-memory 税。它展示了一种常被遗漏的优化：功能重构完成后，反向清点为旧表示服务的 allocator、alignment 与 invariant。

核心技术结论： 补丁删除 ParkEvent::operator new 中“申请 sz + 256、再把地址向上取整”的逻辑，也移除低 8 位必须为零的 guarantee 和不再需要的 NMT/allocation include。operator delete 仍被保留，因为 ParkEvent 可能被陈旧引用观察到，采用 type-stable、实际不释放的生命周期策略；这不是普通地把自定义 allocator 全部删掉。

最有价值的实验、源码与 benchmark 细节： 作者复用 JDK-8393647 的 ThreadSpike.java 创建 10,000 个线程，并用 Native Memory Tracking 比较 Synchronization committed：

before: 8,650,800 bytes
after : 3,520,010 bytes
delta : 5,130,790 bytes (-59.31%)

理论值为 10,000 threads × 2 ParkEvents × 256 bytes = 5,120,000 bytes，与观测差额只约 10.8 KiB，直接把内存变化和分配器实现对上。补丁通过 tier1–3；DaCapo、Renaissance、SPECjvm2008 与 SPECjbb2015 未观察到可重复性能退化。需要注意：-59.31% 是该样本 NMT Synchronization 子项的降幅，不是 JVM 总 RSS 降幅；PR 仍是 Draft。

适合的工程师背景： 熟悉 HotSpot synchronization、parking、NMT，或维护高并发/虚拟线程运行时本地数据结构的 JVM 工程师。

预计阅读收益： 约 25–40 分钟；能看到怎样用历史变更追溯一个 alignment invariant，再用“对象数 × 固定浪费”校验 NMT 结果。

03 · rustc：为新 trait solver 的 identity response 建立零工作快路径

原文与日期： Nicholas Nethercote，2026-10-13；Rust PR #164234、完整源码 diff 与 官方 rustc-perf 对比。

为什么值得读： 新 trait solver 把 canonical query response 实例化回当前 inference context。大量查询的 response 实际是 identity：canonical 变量按原顺序映射回自己，没有外部约束，也不需要 normalization goal；旧路径仍会构造完整 instantiation、fold 列表并再次遍历判断 identity。这个 PR 不改变求解规则，而是逐层移除“答案什么也没改变”时的表示成本，适合迁移到编译器 substitution、IR rewrite 与序列化管线。

核心技术结论： Response 预先缓存 IsIdentity::{No, ModuloRegions, Yes}，替代后续重复执行 is_identity 与 is_identity_modulo_regions 两次遍历；unify_query_var_values 在迭代时逐元素实例化，避免先通过 fold_list intern 整个列表；canonical bound variable 直接索引 instantiation，其他值才走通用 instantiate_value。当 response 没有 inference/external constraints 且 var_kinds 与 goal 一致时，instantiate_and_apply_query_response 直接返回空 normalization goals 与 certainty。

if has_no_inference_or_external_constraints(response)
    && response.var_kinds == canonical_goal_var_kinds
{
    return (NestedNormalizationGoals::empty(), certainty);
}

最有价值的实验、源码与 benchmark 细节： 定向 Diesel next-solver workload 的 instruction count 从旧 solver 的 37.9B 增至新 solver 基线 49.6B（1.31×）；应用本 PR 后降至 45.4B（1.20×）。补丁从新 solver 基线收回 4.2B 指令，即 8.47%，但仍比旧 solver 多约 19.8%，因此不能写成“新 solver 已追平”。

官方 rustc-perf 中，14 个 primary instruction 改善样本平均 -0.6%、范围 -1.5% 到 -0.1%，没有 primary instruction 回退；33 个 secondary 改善样本平均 -3.6%、最好 -12.6%，另有 2 个 secondary 回退，平均 +0.2%。bootstrap 从 512.754 降至 487.269 秒，改善 4.97%；但 secondary cycles 有 2 个回退，平均 +4.1%、最高 +5.4%，一个 secondary max-RSS 样本回退 +5.0%，artifact 从 406.91 增至 409.16 MiB（+0.55%）。最稳妥的结论是“identity-heavy workload 明显少做工作”，而不是所有 crate 全面加速。

适合的工程师背景： 熟悉 rustc 新 trait solver、canonicalization/inference context，或正在优化 substitution 与不可变 IR 遍历成本的编译器工程师。

预计阅读收益： 约 45–60 分钟；能学会从 profile 中识别无效 instantiate/fold，并用定向 workload 与全局 perf suite 共同约束结论。

中国大陆 ToC 硬件价格观察

数据口径

窗口为 2026-09-15 至 2026-10-14，单位人民币，六类硬件固定同一 SKU。今天通过公开比价页的实时渲染结果复核到 CPU、GPU、主板、HDD、SSD 五类报价；DRAM 页面没有可核验报价，因此不新增点。重复价格作为真实采样保留，用来区分“已复核横盘”和“未取得数据”。SSD 商品页只记录固定 2TB 规格的全网比价，不采用跨容量系列起价。

价格来源： 9800X3D、MSI RTX 5070 VENTUS 3X、ASUS TUF B850M-PLUS WIFI7、Kingston FURY DDR5-6000 32GB、IronWolf Pro 8TB、ZHITAI Ti600 2TB。

判断依据

CPU、GPU、主板与 HDD 今日均与昨日持平。主板相对 10 月 11 日仍低 ¥130，实算下降 10.01%，新低连续三日可复核；CPU 已从国庆期间的 ¥2,699 档回落，但没有触及 9 月 23 日的 ¥2,579。Ti600 2TB 从昨日 ¥1,739 回到 ¥1,799，实算上升 3.45%，说明此前两日低点至少在当前渠道没有延续；它只是单一公开比价页的报价事件，不能据此推断 NAND 原厂涨价。GPU 与 HDD 在窗口内持续横盘；DRAM 固定 SKU 继续缺价，走势图保留真实空白尾段。本期没有加入未经核实的新品或产能消息。

本期结论

三项工作都在删除“历史上必要、当前输入下无效”的成本。MGLRU 用尾指针消除锁内链表扫描，HotSpot 在旧锁位编码消失后移除 256 字节对齐，rustc 则识别 identity canonical response 并绕过实例化。工程上可迁移的方法是：先证明哪些工作在当前状态下恒为无效，再把证明条件固化到数据结构、fast path 或 invariant 中；同时保留反例指标，避免用局部吞吐、内存或 instruction count 代替整体结论。