请求分页为何能在不增加周转时间的前提下提升吞吐量？

Great question—this is one of those counterintuitive virtual memory concepts that trips up a lot of folks when they first dive into it. Let’s break this down step by step, tying it back to what Galvin lays out in Operating System Concepts.

先明确几个关键定义 #

• 周转时间: 从进程提交到系统，到它完全执行结束的总时间。
• 吞吐量: 单位时间内系统完成的进程总数。

The confusion often comes from focusing only on the individual process’s disk I/O wait time, but we need to zoom out to the system-wide perspective to see why Galvin’s claim holds.

原因1：请求分页避免了不必要的磁盘I/O #

和预分页（提前加载进程所有页面到内存）不同，请求分页只在进程真正需要某页面时才从磁盘读入。想想看：大多数进程运行时根本不会执行每一行代码或访问每一份数据——比如错误处理模块、很少用到的配置项，或者边缘场景的数据，在常规运行中可能全程都不会被触发。

通过跳过这些无意义的I/O操作，加载进程关键页面的总时间往往比预加载所有页面要短。所以即便有偶尔的页错误，进程的整体I/O开销也可能比全量预加载更低。

原因2：更高的多道程序度让CPU不再空闲 #

请求分页能让更多进程同时驻留在内存中——每个进程只占用它正在使用的内存，而非整个地址空间。这提升了多道程序度：当一个进程等待磁盘I/O时，CPU不会闲置，操作系统可以切换到另一个就绪进程继续工作。

从系统视角看，这意味着单位时间内能完成更多任务（吞吐量提升）。对单个进程来说，它的I/O等待时间和其他进程的执行时间是重叠的。所以即便你的进程因页错误等待，CPU也没浪费这段时间——进程从提交到完成的总时间（周转时间）并不会增加。甚至如果之前CPU经常闲置，现在系统资源利用更充分，平均周转时间反而可能缩短。

原因3：I/O与CPU执行的重叠 #

现代操作系统设计的核心就是让I/O操作和CPU执行重叠进行。当进程触发页错误需要等待磁盘I/O时，操作系统不会停滞，而是切换到另一个就绪进程运行。等到磁盘完成页面加载时，CPU已经在处理其他任务了。

这意味着单个进程的磁盘I/O时间不会直接增加系统总延迟，而是被“隐藏”在其他进程的执行过程中。所以单个进程的周转时间不会上升，而整体吞吐量因为更多进程并行推进而提高。

最后呼应Galvin的观点 #

《操作系统概念》中提到“请求分页可在不增加响应时间或周转时间的前提下提升吞吐量”

这并不是说页错误和磁盘I/O不存在，而是说内存利用率提升、工作负载重叠带来的效率增益，远超过偶尔页错误的开销。核心在于我们更高效地利用了系统资源（CPU、内存、磁盘），而非消除了I/O等待时间。

内容的提问来源于stack exchange，提问作者Kavita