堆内存配置超大页不会直接导致内核死锁，但可能因页表映射刚性、伙伴系统回收阻塞、TLB压力加剧及kcompactd争抢，在高负载下引发资源僵持与调度假死，表现为无日志的系统无响应。
堆内存配置超大页（如2MB或1GB页）本身不会直接导致内核死锁，但当它与内核内存管理关键路径发生耦合冲突时，可能触发分配链路的资源僵持——本质是页表映射、伙伴系统回收与TLB压力三者在高负载下形成正反馈恶化循环，而非传统意义的“加锁-等待”型死锁。下面从内存寻址原理出发，分层说明这个过程。
页表层级与大页映射的刚性约束
现代x86-64 Linux使用四级页表（PGD → PUD → PMD → PTE）。普通4KB页允许逐级按需建立映射；而启用透明大页（THP）或显式hugepage后，内核必须一次性在PMD级（2MB粒度）或PUD级（1GB粒度）分配连续物理页框，并填充对应页表项。这意味着：
- 分配2MB大页时，伙伴系统必须找到一个完整的2MB连续空闲内存块（即1个order-9页块），不能拼接；
- 若物理内存存在大量4KB碎片但缺乏大块连续空间，分配将失败并触发直接回收（direct reclaim）；
- 而直接回收过程中，若又需要映射新页表（例如为回收出的页建立swap映射），就可能再次申请PMD级页表空间——此时若页表自身也因内存紧张而无法分配，就会陷入“为回收而分配，为分配而回收”的递归阻塞。
TLB压力加剧页表遍历开销
大页本意是减少TLB miss，但配置失当时反而恶化调度延迟：
- 当大量进程同时启用大页，且工作集远超TLB容量（如Intel主流CPU仅1024项数据TLB），TLB频繁miss迫使CPU反复访问多级页表；
- 每次页表遍历需至少3~4次内存访问（PGD→PUD→PMD→PTE），若这些访问又触发缺页（如页表页本身被换出），则进入嵌套缺页处理；
- 内核缺页处理函数
handle_mm_fault()在极端情况下会持有mmap_lock读锁，而直接回收路径中的shrink_page_list()又可能尝试获取同一锁——若锁顺序不一致或抢占被禁用（如在中断上下文），就可能造成不可调度的长时间自旋，表现为“假死锁”现象。
内核线程与内存压缩的资源争抢
启用大页后，内核常依赖kcompactd线程进行内存整理以生成连续块。但该线程本身需要内存来构建迁移列表、复制页等：
- 当系统已接近OOM margin，kcompactd申请内存失败会休眠，等待内存释放；
- 而用户进程的大页分配请求又在等待kcompactd完成整理——双方互相等待，且无超时机制；
- 更危险的是，若此时发生软中断（如网络包到达触发SKB分配），而SKB缓存也依赖大页后备，则中断上下文可能调用
__alloc_pages()并禁用抢占，进一步冻结调度器响应能力，使整个CPU核心失去响应。
为什么不是传统死锁，却更难恢复？
这类问题不满足死锁四必要条件中的“循环等待”，因为没有显式锁持有链；但它具备死锁的实质后果：多个内核路径因资源（连续物理页、页表页、TLB条目、锁状态）长期不可达而停滞。由于发生在内存管理底层，panic前往往无有效日志，仅表现为系统无响应或hung_task告警。修复关键在于解耦：关闭THP、预留hugepage内存池、限制单进程大页用量、启用vm.swappiness=0避免swap引发的页表震荡。
