在需求分页中，当进程需要时，页面从磁盘读入内存。 这会导致磁盘I / O的开销，并使进程等待。
现在，我已经阅读了一句话（来自高尔文＆＃39;操作系统概念＆＃39;书籍，＆＃39;虚拟内存＆＃39;章节），指出需求分页可以在不增加响应时间的情况下提高吞吐量或周转时间。
我同意请求分页会增加吞吐量，但是如果它涉及磁盘I / O而不增加周转时间的话怎么可能呢？
示例 考虑在时间0提交给系统的过程。 还要考虑该进程可能必须在设备队列中等待可变的时间量。 流程包含3页。 从磁盘读取内存到内存所需的时间是2ms。 执行该过程所需的总时间为10毫秒。
假设长期计划决定在时间5将进程添加到内存中。
没有需求寻呼：
在内存中加载3页进程需要2 * 3 = 6ms。 然后进程执行10ms。
等待作业队列5 加载进程在内存中6 执行10 因此TAT = 5 + 6 + 10 = 21ms
通过请求分页：
第一页在2ms内加载到内存中。 然后进程执行4ms并需要内存中的下一页。 因此，在磁盘的等待队列中添加进程，等待10ms，然后在2ms内加载第二页。 然后进程执行3ms并要求第三页。 再次进程等待5ms的磁盘，然后页面加载2ms。 然后进程执行3ms并终止。
等待作业队列5 加载第1页2 执行4 等待磁盘10 在内存中加载第二页2 执行3 等待磁盘5 在内存中加载第三页2 执行3 因此，TAT = 5 + 2 + 4 + 10 + 2 + 3 + 5 + 2 + 3 = 36ms
答案 0 :(得分：0)
很容易理解为什么 response time 不会增加。由于您不需要将整个程序从磁盘加载到主内存，因此响应时间肯定不会增加可能会降低因为我们只能在主内存中部分加载程序就可以开始执行。
现在，如何不增加 turnaround time 。主要是因为进程消耗的总时间。因此，假设您没有请求分页，在这种情况下，您首先在主内存中加载整个程序，这仍需要磁盘I / O ，然后开始执行。但是在需求分页中，只有当需要再次需要磁盘I / O 时才按部分加载程序。在最坏的情况下，当需要程序的所有页面时，即使在需求分页中，您也必须将整个程序加载到主存储器中。无论哪种方式，与非需求分页系统相比，您都不执行任何额外的磁盘I / O，因此不会增加周转时间。