Linux 进程状态

Question

在 Linux 中，当进程需要从磁盘读取 block 时，它的状态会发生什么变化？被封锁了吗？如果是，如何选择另一个进程来执行？

Answer 1

当一个进程需要从磁盘获取数据时，它实际上会停止在 CPU 上运行以让其他进程运行，因为该操作可能需要很长时间才能完成——磁盘至少 5 毫秒的寻道时间是常见的，而 5 毫秒是 1000 万个 CPU 周期，从程序的角度来看是永恒的!

从程序员的角度来看(也称为“在用户空间中”)，这称为阻塞系统调用。如果您调用 write(2)(它是同名系统调用的一个精简的 libc 包装器)，您的进程不会完全停止在该边界处；它继续在内核中运行系统调用代码。大多数情况下，它一直到特定的磁盘 Controller 驱动程序(文件名→文件系统/VFS→ block 设备→设备驱动程序)，其中获取磁盘上的 block 的命令被提交给适当的硬件，这是一个非常大部分时间运行速度很快。

然后进程进入 sleep 状态(在内核空间中，阻塞被称为 sleep ——从内核的角度来看，没有任何东西被“阻塞”过)。一旦硬件最终获取了正确的数据，它将被唤醒，然后该进程将被标记为可运行并被调度。最终，调度程序将运行该进程。

最后，在用户空间中，阻塞系统调用返回正确的状态和数据，程序流程继续进行。

可以在非阻塞模式中调用大多数 I/O 系统调用(参见 open(2) 中的 O_NONBLOCK 和 fcntl(2))。在这种情况下，系统调用立即返回并且只报告提交磁盘操作。程序员稍后必须明确检查操作是否完成，成功与否，并获取其结果(例如，使用 select(2))。这称为异步或基于事件的编程。

这里提到 D 状态(在 Linux 状态名称中称为 TASK_UNINTERRUPTIBLE)的大多数答案都不正确。 D 状态是一种特殊的 sleep 模式，它只在内核空间代码路径中触发，当该代码路径不能被中断时(因为它太复杂了程序)，期望它只会阻塞很短的时间。我相信大多数“D 状态”实际上是不可见的；它们的生命周期很短，无法通过“top”等采样工具观察到。

在少数情况下，您可能会遇到处于 D 状态的无法杀死的进程。 NFS 以它而闻名，我遇到过很多次。我认为一些 VFS 代码路径之间存在语义冲突，它假定总是到达本地磁盘和快速错误检测(在 SATA 上，错误超时大约为 100 毫秒)和 NFS，它实际上从网络获取数据更具弹性并且恢复缓慢(300 秒的 TCP 超时很常见)。阅读 this article对于 Linux 2.6.25 中引入的具有 TASK_KILLABLE 状态的酷解决方案。在这个时代之前，有一个黑客可以通过向内核线程 rpciod 发送 SIGKILL 来实际向 NFS 进程客户端发送信号，但忘记那个丑陋的技巧......