进程卡在 D 状态 [kthreadd] 或 [kswapd0] 的深层原因定位

kthreadd卡在D状态基本可排除自身问题，因其仅负责fork内核线程，卡住实为等待子线程（如kswapd0）完成，根源在I/O、内存回收或cgroup限流等下游资源死锁。

为什么 kthreadd 卡在 D 状态基本可以排除进程自身问题

kthreadd 是内核线程的“父进程”，本身不执行业务逻辑，只负责 fork() 出其他内核线程（比如 kswapd0、khungtaskd）。它卡在 D（uninterruptible sleep）状态，几乎总是因为某个它刚 fork 出的子线程卡住了，导致 kthreadd 在 wait_event() 或类似同步点上被阻塞——不是它自己慢，而是它在等别人。

实操建议：

• 先用 ps -eo pid,ppid,comm,wchan:20,state | grep 'D.*kthreadd' 查看哪个子线程在等什么内核函数（wchan 列）
• 再用 cat /proc//stack 看该子线程完整调用栈，重点关注最顶层是否落在 __io_wait_event、sleep_on_bit、mem_cgroup_wait 等 I/O 或内存路径上
• 别急着重启，kthreadd 卡住往往是下游资源（如存储、cgroup 限流、page cache 回写）已死锁的表象

kswapd0 长期 D 状态通常指向内存回收路径受阻

kswapd0 的职责是异步回收内存页，D 状态说明它正卡在某个不可中断的等待中，常见于：设备 I/O 延迟过高、底层块设备无响应、或 cgroup 内存压力下被强制 throttle。和用户态进程不同，它不会因信号中断，所以一旦卡住，整个内存回收就停摆。

实操建议：

• 检查 /proc/vmstat 中 pgmajfault、pgpgin、pgpgout 是否持续飙升，配合 vmstat 1 观察 si/so（swap in/out）是否长期非零
• 用 cat /proc//stack 看栈顶：若停在 blk_mq_get_tag 或 submit_bio，说明块层卡住；若停在 try_to_unmap 或 shrink_inactive_list，可能是特定 page 类型（如 dirty file-backed page）无法释放
• 临时验证：运行 echo 1 > /proc/sys/vm/drop_caches（仅清 pagecache）看是否能唤醒 kswapd0；若不能，大概率是底层存储或驱动问题

定位真正瓶颈：从 /proc/buddyinfo 和 /sys/kernel/debug/block/*/io_stats 入手

D 状态本身只是现象，真正瓶颈往往藏在内存分配器或 I/O 子系统。比如 kswapd0 卡在 balance_pgdat，但实际是因为 buddy allocator 无法满足高阶内存请求（order-3+），进而反复触发更激进的回收，形成恶性循环。

SpeechEasy

SpeechEasy是一种合成语音解决方案，可以让用户从文本生成高质量、易于理解的音频。

下载

实操建议：

• 运行 cat /proc/buddyinfo，关注高阶（order-4 及以上）空闲页是否为 0；若持续为 0，说明内存碎片严重，kswapd0 会不断尝试 compaction，而 compaction 又依赖 I/O 完成，容易卡死
• 检查对应块设备的 debugfs 统计：cat /sys/kernel/debug/block//io_stats，观察 in_flight 是否长期 > 0，且 io_ticks 不增长——这是设备无响应的强信号
• 若使用 NVMe，注意 dmesg 中是否有 nvme nvme0: timeout 或 reset controller 日志；这些会直接让 kswapd0 卡在 nvme_queue_rq

容易被忽略的三个硬性条件

很多排查止步于“看起来像磁盘慢”，但以下三点常被跳过，却直接决定是否真能复现或缓解：

• 确认是否启用了 memory.max（cgroup v2）或 memory.limit_in_bytes（v1）：当容器/进程内存被严格限制，且脏页比例超阈值时，kswapd0 会被强制同步回写，极易卡在 writeback 路径
• 检查是否挂载了 nobarrier 或 noatime 的 ext4/xfs：某些旧内核版本在禁用 barrier 下遇到突发 I/O 错误时，会卡在 __wait_on_bit_lock 等待 page lock，而非报错退出
• 确认内核是否打了特定补丁：例如 5.4.0-105-generic（Ubuntu）存在一个 kswapd 在 memcg under high pressure 下死锁的 bug，需升级到 5.4.0-107+

卡在 D 状态的内核线程本身不提供调试接口，所有线索都来自栈、统计文件和周边子系统状态。最耗时间的往往不是找“哪一行代码卡住”，而是确认“哪一层资源彻底不可达”。