虚拟内存页面替换算法

Question

我有一个项目，要求我开发一个应用程序来模拟不同页面替换算法的执行方式（具有不同的工作集大小和稳定期）。我的结果：

• 垂直轴：页面错误
• 水平轴：工作集尺寸
• 深度轴：稳定期

我的结果合理吗？我希望 LRU 比 FIFO 有更好的结果。在这里，它们大致相同。

对于随机，稳定期和工作集大小似乎根本不影响性能？我期望与 FIFO 和 LRU 类似的图表只是性能最差？如果参考字符串是高度稳定的（小分支）并且工作集大小较小，那么与具有许多分支和大工作集大小的应用程序相比，它的页面错误应该更少吗？

更多信息

My Python Code | The Project Question

• 参考字符串 (RS) 的长度：200,000
• 虚拟内存大小（P）：1000
• 主内存大小（F）：100
• 引用的时间页数（m）：100
• 工作集大小 (e)：2 - 100
• 稳定性（t）：0 - 1

工作集大小 (e) 和稳定期 (t) 会影响参考字符串的生成方式。

|-----------|--------|------------------------------------|
0           p        p+e                                  P-1

所以假设上面的虚拟内存大小为P。要生成引用字符串，使用以下算法：

• 重复直到生成参考字符串
  • 在 [p, p+e] 中选择 m 数字。 m 模拟或引用页面被引用的次数
  • 选择随机数，0
  • 如果 r
  • 生成新的p
  • 否则 (++p)%P

更新（回应@MrGomez 的回答）

不过，回想一下您是如何播种输入数据的：使用 random.random， 从而为您提供可控的数据均匀分布 熵的水平。因此，所有值都同样可能 发生了，因为你是在浮点空间中构建的， 复发的可能性很小。

我正在使用random，但它也不是完全随机的，虽然使用工作集大小和页数引用参数，但引用是在某些地方生成的？

我尝试使用numFrames 增加numPageReferenced 相对值，希望它会更多地引用当前内存中的页面，从而显示LRU 优于FIFO 的性能优势，但这并没有给我一个明确的结果。仅供参考，我尝试了具有以下参数的相同应用程序（页面/帧比率仍然保持不变，我减小了数据大小以加快速度）。

--numReferences 1000 --numPages 100 --numFrames 10 --numPageReferenced 20

结果是

仍然没有那么大的差异。我是否可以说如果我相对于numFrames 增加numPageReferenced，LRU 应该有更好的性能，因为它更多地引用内存中的页面？或者我可能误解了什么？

对于随机，我的思路是：

• 假设有高稳定性和小工作集。这意味着引用的页面很可能在内存中。那么运行页面替换算法的需求会降低吗？

嗯，也许我得再考虑一下:)

更新：稳定性较低时垃圾不太明显

在这里，我试图将垃圾处理显示为工作集大小超过内存中的帧数 (100)。但是，由于稳定​​性较低（高t），注意抖动似乎不太明显，为什么会这样？是否解释为随着稳定性变低，页面错误接近最大值，因此工作集大小无关紧要？

Answer 1

考虑到您当前的实施，这些结果是合理的。但是，其背后的基本原理值得讨论。

在考虑一般算法时，最重要的是考虑当前正在检查的算法的属性。具体来说，请注意他们的corner cases 以及最佳和最坏情况。您可能已经熟悉这种简洁的评估方法，所以这主要是为了那些可能没有算法背景的读者。

让我们通过算法分解您的问题，并在上​​下文中探索它们的组件属性：

1. FIFO 显示页面错误随着工作集（长度轴）大小的增加而增加。

   这是正确的行为，与 Bélády's anomaly 的 FIFO 替换一致。随着工作页面集大小的增加，页面错误的数量也应该增加。

2. FIFO 显示随着系统稳定性（1 - 深度轴）降低，页面错误会增加。

   注意您的播种稳定性算法 (if random.random() < stability)，随着稳定性 (S) 接近 1，您的结果变得不太稳定。随着您急剧增加 entropy在您的数据中，页面错误的数量也急剧增加并传播了 Bélády 异常。

   到目前为止，一切都很好。

3. LRU 显示与 FIFO 的一致性。为什么？

   注意您的播种算法。 Standard LRU 在您的寻呼请求被构建为较小的操作帧时是最佳选择。对于有序的、可预测的查找，它改进了 FIFO通过老化当前执行帧中不再存在的结果，这对于分阶段执行和封装的模态操作非常有用。再说一次，到目前为止，一切都很好。

   但是，回想一下您是如何播种输入数据的：使用 random.random，从而为您提供 uniform distribution 的数据，并具有可控的熵水平。因此，所有值出现的可能性均等，并且因为您在 floating point space 中构造了它，所以重复发生的可能性非常小。

   因此，您的 LRU 会感知每个元素发生少量次数，然后在计算下一个值时被完全丢弃。因此，它会在每个值落出窗口时正确地对其进行分页，从而为您提供与 FIFO 完全可比的性能。如果您的系统正确考虑了重复或压缩字符空间，您会看到明显不同的结果。

4. 对于随机而言， 稳定期和工作集大小似乎根本不会影响性能。为什么我们在整个图表上都看到这个涂鸦，而不是给我们一个相对的smooth manifold？

   在随机分页方案的情况下，您将老化每个条目stochastically。据称，这应该为我们提供某种形式的流形，该流形与工作集的熵和大小绑定......对吗？

   还是应该？对于每组条目，您随机分配一个子集作为时间的函数进行分页。这应该提供相对均匀的分页性能，无论稳定性和您的工作集如何，只要您的访问配置文件再次统一随机。

   因此，根据您检查的条件，这是完全正确的行为consistent with what we'd expect。您获得的分页性能不会因其他因素而降低（但相反，不会因其他因素而降低），适用于高负载、高效的操作。不错，只是不是您可能直观地期望的那样。

因此，简而言之，这就是您的项目当前实施时的细分。

作为进一步探索这些算法在输入数据的不同处置和分布的上下文中的属性的练习，我强烈建议深入研究scipy.stats，看看例如高斯或逻辑分布可能对每个算法产生什么影响图形。然后，我会回到 the documented expectations of each algorithm 并草拟每个最合适和最不合适的案例。

总而言之，我认为您的老师会感到自豪。 :)