【发布时间】：2016-03-09 13:15:49
【问题描述】：
我有一个关于操作系统中用于页面替换的 WSClock 算法的问题。
据我了解，WSClock 结合了两个工作集的功能（如果在最后 T 时间间隔内引用了一个页面，则该页面在 WS 中，因此每个页面的最后参考时间都存储有 R&M 位) 和 Clock 算法（页框表存储为循环列表，当发生缺页时，遍历列表查找工作集中不存在的页）。
在每个页面引用中，HW 将其 R 位设置为 1。在某些时间间隔内，操作系统将所有页面的 R 位重置为 0。
当发生页面错误时，算法会遍历列表并对每个页面执行以下操作：
1) If R == 1 : set R = 0, set t = process_t, go further
2) Else if R == 0 and (t - process_t) <= T, go further
3) Else if R == 0 and (t - process_t) > T
1) If M = 1 - set page for writing to disk, go further
2) If M = 0 - this is our victim, evict
If there are no pages for immediate evict are found - traverse until a disk write for any marked page is finished, then evict.
If there are no pages scheduled for a disk write - take the one which was referenced to the most time ago.
算法对我来说看起来还不错，除了一件事：
最后一次引用页面的时间仅在一次更改：如果在引用此页面后发生页面错误（R = 1）但操作系统尚未将 R 位重置为 0（R = 0)。因此，据我了解 - 最后使用的时间仅通过导致更好性能的方法来近似。
因此，对于毫无疑问存在于进程的 WS 中的真正经常使用的页面，一切都很好：它们的参考频率高于操作系统重置事件的频率。
但是应该有一些不幸的页面被频繁地引用，但不幸的是，在这些引用之后没有发生页面错误。但是它们也很不幸，以至于当页面错误发生时——它们看起来好像没有被引用，尽管这不是真的。
因此，从我看来，操作系统似乎只在页面错误事件期间拍摄工作集的快照。这些快照表示在 R 位重置和页面错误之间的时间间隔中引用的工作页面集。
为什么这是真实工作集的良好近似？
近似的质量（以及算法的有效性）是否由重置 R 位时的时间间隔的值决定？
所以这个值不应该太低以至于不能捕捉到我上面提到的大多数这些不幸的页面，但也不应该太大而不能捕捉到实际上已经不在工作集中的页面？
【问题讨论】：
-
只是总结上面写的内容：1）页面引用时间戳何时更改是根据页面错误频率确定的。在我看来，更改此时间戳也更有意义，也基于所有页面框架的某种类型的计时器，这可能比实际工作集更接近 2）取决于页面错误是否在某些时候变得非常罕见- 工作集将是空的（或至少包含在位复位和下一个页面错误之间引用的页面）。这很奇怪。
标签： operating-system paging virtual-memory working-set