__alloc_pages_cpuset_fallback()是一个专门为__GFP_NOFAIL分配请求设计的后备分配函数。它的核心策略是先尝试遵守 cpuset 内存节点限制如果失败则放弃该限制再试一次。核心逻辑两步分配逐步放宽限制它的实现非常直接体现了“先守规矩再破例”的层次感static inline struct page * __alloc_pages_cpuset_fallback(gfp_t gfp_mask, unsigned int order, unsigned int alloc_flags, const struct alloc_context *ac) { struct page *page; /* 第一次尝试严格遵守 cpuset 的节点限制 */ page get_page_from_freelist(gfp_mask, order, alloc_flags | ALLOC_CPUSET, ac); /* * fallback to ignore cpuset restriction if our nodes * are depleted */ /* 第二次尝试如果第一次失败则忽略 cpuset 限制 */ if (!page) page get_page_from_freelist(gfp_mask, order, alloc_flags, ac); return page; }关键点在于对ALLOC_CPUSET标志的处理第一次调用通过alloc_flags | ALLOC_CPUSET强制加上ALLOC_CPUSET标志get_page_from_freelist会严格遵守 cpuset 限制的节点。第二次调用直接使用传入的alloc_flags。因为调用方传入的alloc_flags通常不包含ALLOC_CPUSET所以这次分配会忽略 cpuset 限制允许从其他节点获取内存。历史背景为__GFP_NOFAIL提供“逃生通道”这个辅助函数是Michal Hocko 在 2016 年引入的commit 系列 “help __GFP_NOFAIL allocations which do not trigger OOM killer”。要解决的问题某些__GFP_NOFAIL分配例如文件系统代码中的GFP_NOFS|__GFP_NOFAIL被要求必须成功且不能失败但它们无法触发 OOM killer。这可能导致它们在某些极端情况下永远循环因为并行的分配请求可能持续“饿死”它们。解决方案给这些“不容失败”的请求一个有限的逃生通道——允许它们消耗一小部分内存保留并突破 cpuset 限制。补丁的说明指出__GFP_NOFAIL请求被认为足够重要可以允许“cpuset runaway”以让系统继续推进。而且这类分配几乎不可能是GFP_USER所以突破 cpuset 限制的风险很低。调用场景它主要在内存分配的慢速路径slowpath中作为最后的挽救手段被调用OOM 路径中在__alloc_pages_may_oom()中当 OOM killer 被触发或__GFP_NOFAIL被警告后会调用它并传入ALLOC_NO_WATERMARKS标志让请求可以动用内存保留。慢速路径循环中在__alloc_pages_slowpath()的重试循环里会使用ALLOC_HARDER标志调用它。注释解释这里使用ALLOC_HARDER而非ALLOC_NO_WATERMARKS是为了避免耗尽全部内存保留而使情况恶化。总结__alloc_pages_cpuset_fallback()是一个cpuset 限制的“两步逃逸”机制它为__GFP_NOFAIL这类“必须成功”的分配请求提供了一条在严格遵守 cpuset 限制失败后能够突破限制、确保系统继续推进的路径。它通过两次调用get_page_from_freelist以ALLOC_CPUSET标志的“有/无”来区分“守规矩”和“破例”两种尝试是内核在极端内存压力下平衡资源隔离策略与系统整体可靠性的巧妙设计。
