上周测某云刚更的Linux7.0稳定镜像，给32卡的大模型训练集群做适配，踩了个藏得极深的坑——7.0改了内存规整（compaction）的触发阈值，之前留10%空闲才触发，现在降到3%。大模型训练全靠1GB HugePages撑内存带宽，当节点混跑训练+KV缓存时，阈值调低反而凑不齐连续物理内存，HugePages分配失败，偶发OOM。之前的监控脚本只盯总内存，没抓compaction的触发频率，硬查了三天才定位。给做AI infra的兄弟提个醒，先别着急更生产镜像，得先测HugePages的分配成功率。有没有同踩这坑的？

天啊这个帖子看得我头皮发麻！你们知道吗我前东家就是搞AI infra的，去年也遇到过类似的HugePages坑，不过是6.4升6.5的时候当时有个哥们半夜三点在Slack里发疯说训练任务突然掉到龟速，查了一通发现是transparent hugepages的defrag策略被偷偷改了，导致分配效率暴跌。最骚的是那个patch的提交者是个刚毕业的实习生，commit message就写了句"optimize defrag logic"，连测试用例都没加全就merge了。后来我们老大在邮件列表里跟maintainer吵了三天，最后发现那个实习生是maintainer的PhD学生… literally 学术圈的小圈子操作。

等等楼主说的这个3%阈值调整，我好像在上个月的lkml邮件归档里瞥见过讨论片段。是不是跟那个"aggressive compaction for latency-sensitive workloads"的提案有关？我记得有个Google的工程师在thread里疯狂反对，说这会导致数据库和大模型这种需要连续内存的应用雪崩，但Red Hat那边的人坚持说这能改善普通工作负载的尾延迟。现在看这波是Red Hat赢了？btw你们有没有注意到最近Linux kernel的memory management组里Red Hat的人越来越多，感觉快成他们家的后花园了…

话说回来，32卡集群用1GB HugePages，这配置听起来像在做MoE模型啊？我听说某家做千亿参数MoE的厂子就特别喜欢用1GB的页，因为专家路由的时候地址跳得太随机，2MB的页TLB miss会爆。不过他们好像自己魔改了kernel，在compaction触发前会先尝试从CMA区域抢内存，不走常规路径。哈哈楼主你们要不要试试这个野路子？虽然可能会被OOM killer反杀…

我好奇的是监控脚本这块。你们之前只盯总内存，那现在加了什么metrics？是不是得把/proc/vmstat里的compact_*系列全扫一遍？还有那个nr_hugepages和nr_overcommit_hugepages的差值变化率要不要监控？上次我们组有个神仙写了个eBPF程序挂在__alloc_pages_slowpath上，专门抓HugePages分配失败的调用栈，结果发现30%的失败居然是因为cgroup memory limit设得太抠门… 笑死，根本和kernel没关系。

最后小声问个八卦：某云更新镜像这么激进，是不是因为他们家最近在推那个"AI原生云"的营销概念？我听说他们KPI压得特别狠， infra团队为了赶发布时间经常跳过灰度直接全量推。上个月不是还有个新闻说他们某个region的GPU实例批量宕机，原因就是强制升级了NVIDIA驱动但没测透CUDA兼容性… 感觉国内这些云厂商的devops成熟度还得再练练啊。

不过楼主能三天定位出来也是真大佬了，我们当年那个坑折腾了快两周，最后是靠着在/proc/<pid>/smaps里发现某个第三方库在疯狂用madvise(MADV_DONTNEED)才破案。现在想想ICU出来之后真是看开了，这种debug过程虽然痛苦，但找到root cause的那一刻的快乐，比什么摇滚现场都带劲… 虽然第二天可能就因为另一个坑继续熬夜就是了（笑
太！
突然想到对了，你们有没有试过用cgroup v2的memory.high做软限来缓解这种问题？我最近在玩这个，感觉比粗暴的OOM killer温柔多了…