事实上,需要研究一下没有“足够”帧的进程。如果进程没有需要支持活动使用页面的帧数,那么它会很快产生缺页错误。此时,必须置换某个页面。然而,由于它的所有页面都在使用中,所以必须立即置换需要再次使用的页面。因此,它会再次快速产生缺页错误,再一次置换必须立即返回的页面,如此快速进行。
这种高度的页面调度活动称为抖动。如果一个进程的调页时间多于它的执行时间,那么这个进程就在抖动。
系统抖动的原因
抖动导致严重的性能问题。考虑以下场景,这是基于早期调页系统的实际行为。
操作系统监视 CPU 利用率。如果 CPU 利用率太低,那么通过向系统引入新的进程来增加多道程度。采用全局置换算法会置换任何页面,而不管这些页面属于哪个进程。
现在假设进程在执行中进入一个新阶段,并且需要更多的帧。它开始出现缺页错误,并从其他进程那里获取帧。然而,这些进程也需要这些页面,因此它们也会出现缺页错误,并且从其他进程中获取帧。这些缺页错误进程必须使用调页设备以将页面换进和换出。当它们为调页设备排队时,就绪队列清空。随着进程等待调页设备,CPU 利用率会降低。
CPU 调度程序看到 CPU 利用率的降低,进而会增加多道程度。新进程试图从其他运行进程中获取帧来启动,从而导致更多的缺页错误和更长的调页设备队列。因此,CPU 利用率进一步下降,并且 CPU 调度程序试图再次增加多道程度。这样就出现了抖动,系统吞吐量陡降,缺页错误率显著增加。结果,有效内存访问时间增加,没有工作可以完成,因为进程总在忙于调页。
图 1 系统抖动
这种现象如图 1 所示,这里 CPU 利用率是按多道程度来绘制的。随着多道程度的增加,CPU 利用率也增加,虽然增加得更慢,直到达到最大值。如果多道程度还要进一步增加,那么系统抖动就开始了,并且 CPU 利用率急剧下降。此时,为了提高 CPU 利用率并停止抖动,必须降低多道程度。
通过局部置换算法或优先级置换算法,可以限制系统抖动。如果一个进程开始抖动,那么由于采用局部置换,它不能从另一个进程中获取帧,而且也不能导致后者抖动。然而,这个问题并没有完全解决。如果进程抖动,那么在大多数时间内会排队等待调页设备。由于调页设备的平均队列更长,缺页错误的平均等待时间也会增加。因此,即使对于不再抖动的进程,有效访问时间也会增加。
为了防止抖动,应为进程提供足够多的所需帧数。但是如何知道进程“需要”多少帧呢?有多种技术。工作集策略研究一个进程实际使用多少帧。这种方法定义了进程执行的局部性模型。
局部性模型指出,随着进程执行,它从一个局部移向另一个局部。局部性是最近使用页面的一个集合(图 2)。一个程序通常由多个不同的可能重叠的局部组成。
图 2 内存引用模式中的局部性
例如,当一个函数被调用时,它就定义了一个新的局部。在这个局部里,内存引用可针对函数调用的指令、它的局部变量以及全局变量的某个子集。当退出函数时,进程离开该局部,因为这个函数的局部变量和指令已不再处于活动使用状态。以后可能回到这个局部。
因此,可以看到局部是由程序结构和数据结构来定义的。局部性模型指出,所有程序都具有这种基本的内存引用结构。注意,局部性模型是目前为止缓存讨论的背后原理。如果对任何数据类型的访问是随机的而没有规律模式,那么缓存就没有用了。
假设为进程分配足够的帧以适应当前局部。该进程在其局部内会出现缺页错误,直到所有页面都在内存中;接着它不再会出现缺页错误,除非改变局部。如果没有能够分配到足够的帧来容纳当前局部,那么进程将会抖动,因为它不能在内存中保留正在使用的所有页面。
工作集模型
如上所述,工作集模型是基于局部性假设的。这个模型采用参数 △ 定义工作集窗口。它的思想是检查最近 △ 个页面引用。这最近 △ 个页面引用的页面集合称为工作集(如图 3 所示)。
图 3 工作集模型
如果一个页面处于活动使用状态,那么它处在工作集中。如果它不再使用,那么它在最后一次引用的 △ 时间单位后,会从工作集中删除。因此,工作集是程序局部的近似。
例如,给定如图 3 所示的内存引用序列,如果 △ 为 10 个内存引用,那么 t1 时的工作集为 {1,2, 5,6,7}
。到 t2 时,工作集已经改变为 {3,4}
。
工作集的精度取决于△的选择。如果 △ 太小,那么它不能包含整个局部;如果 △ 太大,那么它可能包含多个局部。在极端情况下,如果 △ 为无穷大,那么工作集为进程执行所需的所有页面的集合。
因此,最重要的工作集属性是它的大小。如果系统内的每个工作集通过计算为 WSS,那么就得到:
D=ΣWSSi
这里 D 为帧的总需求量。每个进程都使用其工作集内的页面。因此,进程 i 需要 WSSi 帧。如果总需求大于可用帧的总数(D>m),则将发生抖动,因此有些进程得不到足够的帧数。
一旦选中了 △,工作集模型的使用就很简单。操作系统监视每个进程的工作集,并为它分配大于其工作集的帧数。如果还有足够的额外帧,那么可启动另一进程。如果工作集大小的总和增加,以致超过可用帧的总数,则操作系统会选择一个进程来挂起。该进程的页面被写出(交换),并且其帧可分配给其他进程。挂起的进程以后可以重启。
这种工作集策略可防止抖动,同时保持尽可能高的多道程度。因此,它优化了 CPU 利用率。工作集模型的困难是跟踪工作集。工作集窗口是一个移动窗口。对于每次内存引用,新的引用出现在一端,最旧的引用离开另一端。如果一个页面在工作集窗口内的任何位置被引用过,那么它就在工作集窗口内。
通过定期时钟中断和引用位,我们能够近似工作集模型。
例如,假设 △ 为 10 000 个引用,而且每 5000 个引用引起定时器中断。当得到一个定时器中断时,复制并清除所有页面的引用位。如果发生缺页错误,那么可以检查当前的引用位和位于内存的两个位,这两位可以确定在过去的 10 000〜15 000 个引用之间该页面是否被使用过。如果使用过,那么这些位中至少有一位会被打开。如果没有使用过,那么这些位会被关闭。至少有一位打开的页面会被视为在工作集中。
注意,这种安排并不完全准确,这是因为并不知道在 5000 个引用内的什么位置出现了引用。通过增加历史位的数量和中断的频率(例如,10 位和每 1000 个引用中断一次),可以降低这一不确定性。然而,服务这些更为频繁中断的成本也会相应更高。
缺页错误频率
虽然工作集模型是成功的而且工作集的知识能够用于预先调页,但是用于控制抖动似乎有点笨拙。采用缺页错误频率(PFF)的策略是一种更为直接的方法。
这里的问题是防止抖动。抖动具有高缺页错误率。因此,需要控制缺页错误率。当缺页错误率太高时,我们知道该进程需要更多的帧。相反,如果缺页错误率太低,则该进程可能具有太多的帧。
图 4 缺页错误频率
我们可以设置所需缺页错误率的上下限(图 4)。如果实际缺页错误率超过上限,则可为进程再分配一帧;如果实际缺页错误率低于下限,则可从进程中删除一帧。因此,可以直接测量和控制缺页错误率,以防止抖动。
与工作集策略一样,也可能不得不换出一个进程。如果缺页错误率增加并且没有空闲帧可用,那么必须选择某个进程并将其交换到后备存储。然后,再将释放的帧分配给具有高缺页错误率的进程。
实际上,抖动及其导致的交换对性能的负面影响很大。目前处理这一问题的最佳实践是,在可能的情况下提供足够物理内存以避免抖动和交换。从智能手机到大型机,提供足够内存,可以保持所有工作集都并发地处在内存中,并且提供最好的用户体验(除非在极端条件下)。
原创文章,作者:奋斗,如若转载,请注明出处:https://blog.ytso.com/22007.html