【问题标题】:Why is LRU better than FIFO?为什么 LRU 比 FIFO 好?
【发布时间】:2011-01-04 17:31:03
【问题描述】:

为什么Least Recently Used 在页面文件方面比 FIFO 更好?

【问题讨论】:

  • 这与“CS 4xx - 操作系统”有关吗?
  • 为什么要保留您无法访问的内容?为什么不为需要的东西留出空间?

标签: algorithm file fifo lru


【解决方案1】:

如果您的意思是将内存页面卸载到磁盘 - 如果您的进程经常访问一个页面,那么您真的不希望它被分页到磁盘,即使它是您访问的第一个页面。另一方面,如果您已经好几天没有访问内存页面,那么您在不久的将来就不太可能这样做了。

如果这不是您的意思,请编辑您的问题以提供更多详细信息。

【讨论】:

    【解决方案2】:

    没有一种单一的缓存算法会一直做得很好,因为这需要对未来有完全的了解。 (如果你知道从哪里得到它……) LRU 在 VM 缓存设计中的主导地位是长期测量系统行为的结果。给定实际工作负载,LRU 在很大一部分时间里都能很好地工作。但是,构造一个引用字符串并不难,FIFO 的性能优于 LRU。

    考虑对比可用的可分页实内存大得多的大地址空间进行线性扫描。 LRU 是基于“你最近触摸过的东西很可能会再次触摸”的假设,但线性扫描完全违反了这个假设。这就是为什么一些操作系统允许程序就它们的引用行为向内核提供建议的原因——一个例子是经典 LISP 解释器所代表的“标记和清除”垃圾收集。 (并且是“世代”等更现代 GC 工作的主要驱动力。)

    另一个例子是某个古董宏处理器(STAGE2)中的符号表。从根开始搜索二叉树以查找每个符号,并且在堆栈上进行字符串评估。事实证明,通过“向下连接”符号树的根页和堆栈的底部页减少可用的页框,极大地提高了页面错误率。缓存很小,而且搅动得很厉害,总是推出两个最常被引用的页面,因为缓存小于这些页面的引用间距离。所以缓存效果更好,但这只是因为从缓存中窃取的那两个页面框架被明智地使用了。

    所有这一切的结果是,LRU 是标准答案,因为它通常非常适合系统上的实际工作负载,这些系统没有严重超载(VM 是可用实际内存的许多倍),并且经过多年的仔细测量支持.然而, 您当然可以找到替代行为更好的情况。这就是测量真实系统很重要的原因。

    【讨论】:

    • 实际上,对于线性扫描,LRU 和 FIFO 将是相同的(相当糟糕)。您可以构建一个 FIFO 比 LRU 更好的访问模式,但它相当做作。
    • @ChrisDodd 你能描述一个例子,当 FIFO 比 LRU 表现更好?
    【解决方案3】:

    Treat the RAM as a cache。为了成为有效的缓存,它需要将最有可能被请求的项目保存在内存中。

    LRU 将最近使用的东西保存在内存中。 FIFO 保留最近添加的内容。 LRU一般来说效率更高,因为一般有内存项被添加一次就不再使用,也有一些项被频繁添加和使用。 LRU 更有可能将常用项目保留在内存中。

    【讨论】:

      【解决方案4】:

      根据访问模式,FIFO 有时可以击败 LRU。 Adaptive Replacement Cache 是混合型,可根据实际使用模式调整其策略。

      【讨论】:

        【解决方案5】:

        根据temporal locality of reference,最近访问过的内存很可能很快会再次被访问。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2012-04-09
          • 1970-01-01
          • 2011-09-04
          • 2020-04-27
          • 2017-06-30
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多