当代操作系统中的调度程序隐式地为 I/O 密集型进程赋予比 CPU 密集型进程更高的优先级。您是否认为在调度进程时，与 I/O 密集型进程相比，CPU 密集型进程应该被赋予更高的优先级，以便提高吞吐量。
如果服务 IO 的优先级较低，则在处理器执行非 IO 进程时可能会丢失某些输入，这几乎肯定是不好的。这就是为什么 IO 进程的更高优先级是不可避免的。如果这是一个问题，您需要一个以其他方式安排的操作系统。
IMO考虑的是服务更多的流程，而不是只完成一个流程。我也同意 @sharptooth 的观点，即通过允许提供更多 I/O 请求将允许更好地处理 I/O。同时CPU也可以为其他进程服务。整个系统将产生更多的吞吐量。
I/O 密集型任务只需要少量的 CPU 时间来唤醒、收集结果并提交下一个请求。 但是 I/O 队列大小是有限的，如果不使用异步 I/O，可能会非常小（例如打开一个文件并读取它，然后关闭它并打开另一个文件并读取它。）
因此需要在 I/O 完成时唤醒，以避免损失大量 I/O 吞吐量。 当读取大文件时，操作系统的软件预读可以将数据带入页面缓存，以便未来的
readwrite从网络读取也可能具有较小的队列大小（套接字缓冲区））0，对于 UDP，这可能意味着丢失数据包。对于 TCP，耗尽套接字缓冲区为内核可以发送 ACK 的更多数据腾出了空间。 Unix 管道缓冲区通常并不大，比如 64 KiB，因此未能唤醒简单的读取器可能会导致写入器阻塞，或者如果读取器是 CPU 密集型的，则反之亦然。
一些 I/O 绑定任务实际上是“交互式”的，当 I/O 发生在键盘/鼠标事件上或响应它们时，因此吞吐量不是唯一的考虑因素。 对于通用计算机来说，实现稍高 CPU 吞吐量但不能重叠 CPU 限制和 I/O 限制工作负载的调度程序并不是一个好的调度程序。例如如果您还运行不进行 I/O 的数字运算模拟，则复制、下载或上传大文件不会减慢太多速度。