问题标签 [page-replacement]

FreeBSD 使用分页队列实现页面着色。队列根据处理器的 L1 和 L2 缓存大小排列；当需要分配一个新页面时，FreeBSD 会尝试获取一个与缓存最佳对齐的页面。

有人可以解释一下上述几行，分页队列的概念是什么？

谢谢！

我正在重新制定这个问题，因为我现在更好地理解了这个问题。

我有一个包含四个模型的应用程序：用户、产品、品种和季节。

用户
has_many :seasons
has_many :products, :through => :seasons
has_many :varieties, :through => :seasons

产品
has_many :seasons
has_many :users, :through => :seasons
has_many :varieties

种类
belongs_to :product
has_many :seasons
has_many :users, :through => :seasons

四季
belongs_to :product
belongs_to :user
belongs_to :variety

在产品/展示视图中，我列出了可用于特定产品的每个品种，以及携带该特定产品的用户。

首次加载产品/展示页面时，我会通过以下方式显示所有携带该产品的用户：

我还通过这样做列出了产品可用的品种：

这就是 Ajax 需要发生的地方。当我点击品种名称时，我想用@variety.seasons 替换@product.seasons 循环。我认为这应该只显示具有特定种类的用户。所以看起来像这样：

我越来越近了，但我无法让它工作。目前，当我点击一个品种时，前端什么也没有发生。在日志中，我得到这个：

日志引用 #4 并将 4 称为操作。4 是我点击的商品的品种 ID。

这是我的设置：

ProductsController#show
@product = Product.find(params[:id])
@varieties = @product.varieties @users = @product.users

Product/show view #列出拥有该产品的用户

品种控制器#show。

品种/show.js.rjs
@page.replace_html "userList", :partial => "products/users", :collection => @variety.users

因此，目前，页面正在渲染和显示正确的 html 和数据。但是 onclick 不起作用。当我点击一个品种时，应用程序没有正确处理请求并且用户列表没有改变。

更新

回应 Anatoliy 的评论：

我不确定到底需要添加什么路线。我尝试添加以下内容，但结果与之前相同：

map.resources :varieties, :member => { :show => :get }

您能否更具体地说明应该调用什么成员路由？

我正在运行一个模仿需求分页系统的代码，这里有一些参数：

我使用先进先出或随机页面替换算法运行我的代码，页面帧数设置为 100。我的磁盘读/写以 63 结束。

然后，当我将处理器大小更改为 32 位时 - 此边界移动到 16。

后一种情况，我理解。如果页帧计数超过可能的页表条目，则 (2^4) 不需要驱逐。

但我不明白为什么在前一种情况下，页表条目上升到 2^20，磁盘读/写在 63 处停止，两种页面替换算法。

这个神秘的 63 号码是什么？知道这可能来自哪里吗？谢谢你。

作为我的操作系统作业的一部分，我被要求比较给定页面访问序列的先进先出和最近最少使用的页面替换策略产生的页面错误数量。令人困惑的是，FIFO 产生的页面错误似乎比 LRU 少。这是可能的，还是我犯了一个错误？

I have a project where I am asked to develop an application to simulate how different page replacement algorithms perform (with varying working set size and stability period). My results:

• Vertical axis: page faults
• Horizontal axis: working set size
• Depth axis: stable period

Are my results reasonable? I expected LRU to have better results than FIFO. Here, they are approximately the same.

For random, stability period and working set size doesnt seem to affect the performance at all? I expected similar graphs as FIFO & LRU just worst performance? If the reference string is highly stable (little branches) and have a small working set size, it should still have less page faults that an application with many branches and big working set size?

More Info

My Python Code | The Project Question

• Length of reference string (RS): 200,000
• Size of virtual memory (P): 1000
• Size of main memory (F): 100
• number of time page referenced (m): 100
• Size of working set (e): 2 - 100
• Stability (t): 0 - 1

Working set size (e) & stable period (t) affects how reference string are generated.

So assume the above the the virtual memory of size P. To generate reference strings, the following algorithm is used:

• Repeat until reference string generated
  • pick m numbers in [p, p+e]. m simulates or refers to number of times page is referenced
  • pick random number, 0 <= r < 1
  • if r < t
    • generate new p
    • else (++p)%P

UPDATE (In response to @MrGomez's answer)

However, recall how you seeded your input data: using random.random, thus giving you a uniform distribution of data with your controllable level of entropy. Because of this, all values are equally likely to occur, and because you've constructed this in floating point space, recurrences are highly improbable.

I am using random, but it is not totally random either, references are generated with some locality though the use of working set size and number page referenced parameters?

I tried increasing the numPageReferenced relative with numFrames in hope that it will reference a page currently in memory more, thus showing the performance benefit of LRU over FIFO, but that didn't give me a clear result tho. Just FYI, I tried the same app with the following parameters (Pages/Frames ratio is still kept the same, I reduced the size of data to make things faster).

The result is

Still not such a big difference. Am I right to say if I increase numPageReferenced relative to numFrames, LRU should have a better performance as it is referencing pages in memory more? Or perhaps I am mis-understanding something?

For random, I am thinking along the lines of:

• Suppose theres high stability and small working set. It means that the pages referenced are very likely to be in memory. So the need for the page replacement algorithm to run is lower?

Hmm maybe I got to think about this more :)

UPDATE: Trashing less obvious on lower stablity

Here, I am trying to show the trashing as working set size exceeds the number of frames (100) in memory. However, notice thrashing appears less obvious with lower stability (high t), why might that be? Is the explanation that as stability becomes low, page faults approaches maximum thus it does not matter as much what the working set size is?

我试图理解 LRU，它对我来说毫无意义。如果我理解它，那么我将更容易编码。有人可以帮我完成这些步骤吗？像，

1. 如果您当前所在的引用字符串在数组中，那么您是否递增到下一个空格？
2. 当您检查缓冲区中是否有东西时，我们是否需要扫描我们所在的位置或整个阵列？

我似乎无法跟上。它如何跟踪最近最少使用的？最近最少使用的不应该是您所在索引之后的那个吗？

MFU（最常用）页面替换算法什么时候比LRU（最不常用）有更好的性能？什么时候比LRU差？除了 MFU 页面替换算法的基本定义之外，我在哪里可以找到信息？

我正在尝试了解 FIFO 页面替换算法，但我能找到的所有信息都属于以下内容。您能解释一下如何使用参考字符串来评估页面替换算法，使用 FIFO 的特定示例吗？

当必须替换页面时，将选择最旧的页面。

在我们所有的例子中，参考字符串是

1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5

3 帧（9 个页面错误） 4 帧（10 个页面错误）

我正在编写一个程序来使用 C# 中的 FIFO 查找页面错误。用户要么提供一个 20 个字符的参考字符串，要么生成一个随机的参考字符串。用户还输入帧数。

因此，我将 20 个个位数的数组、帧数组和帧数传递给我的 FIFO 函数。出于某种原因，我的号码已关闭，我不确定自己做错了什么。我正在使用 1 2 3 4 2 1 5 6 2 1 2 3 7 6 3 2 1 2 3 6 的参考字符串进行 4 帧测试，我似乎得到 56，而我应该得到 14 个故障。下面是我的 FIFO 函数。

我正在尝试编写一个模拟 LRU 页面替换的函数。我非常了解 LRU，但在编码时遇到问题。以下内容被传递到 LRU 函数中。用户指定 # 的 1-9 的 20 个字符的引用字符串，该字符串存储在大小为 20 的称为 refString 的数组中。用户输入的帧数 (1-7) 存储在变量 numFrames 中。最后，传入一个名为 frame 的大小为 7 的数组。

这是我的代码，我得到的数字很接近，但并不完全。也许有人可以帮忙！