问题标签 [page-fault]

我正在尝试在 JAVA 上调整我的一个应用程序。我正在使用 JAVA-Profiler 并从中获得了一些报告。我看到应用程序的页面错误数量从 30000 到 35000 不等。我怎样才能确定这个数字是太高还是正常？我在最初的一分钟和半小时后得到相同的数据。

我的 RAM 是 2 GB，我正在使用单线程应用程序。

线程仅尝试每 3 秒从队列中读取消息，并且队列为空。

由于没有进行任何处理，我认为根本不应该发生页面错误。请在这里指导我。

有谁知道如何获取导致页面错误的内存访问（指针）？我主要对主要的页面错误感兴趣。

关于我想要实现的目标的一些背景知识。我有一个内存占用很大的应用程序（数据库），我想将分页与对大型数据结构（例如使用 mmap() 分配的表、索引）的访问相关联。进程的映射很容易从 /proc//maps 中检索。现在，如果我有导致页面错误的内存访问，我可以跟踪在访问每个数据结构时导致了多少页面错误。

我认为 perf 或 systemtap 可以完成这项工作。有任何想法吗？

我正在努力学习考试。我找到了这个例子，但不明白他们是如何得到答案的。谁能解释一下吗？

问题：

考虑二维数组 A： int A[][] = new int[100][100]; 其中 A[0][0] 位于页面大小为 200 的分页内存系统中的位置 200。操作矩阵的小进程位于页面 0（位置 0 到 199）中。因此，每条指令都将从第 0 页获取。对于两个页框，使用 LRU 替换并假设第一个页框包含进程而另一个页框最初为空，以下数组初始化循环会生成多少页错误？

A：

乙：

给出的正确答案是：a：100 x 50 = 5000 b：50

我有点理解第一部分。共有50页。(10000/200=50) 并且每次 j 发生变化时，都会发生页面错误..所以总共有 100 个页面错误..但是为什么要乘以 50？为什么第二个是50？

谢谢！！

在阅读页面错误异常处理程序如何处理页面错误和页面命中时，我不清楚一件事。如果一个进程正在使用共享页并且发生了页错误，那么当页错误异常处理程序为导致该页错误的进程更新页表中的页表条目时，它是否也会更新所有共享页中的页表条目？共享同一页面的其他进程？从我对该主题的阅读来看，它似乎只更新了页表中错误进程的页表条目，但是其他进程如何知道该页面已被调入？提前致谢！

您可以在页面错误处理程序中启用中断吗？是否存在抢占式调度的 ARM 内核争用？

我在 UDP 中使用 CONFIG_PREEMPT 接收代码，或者在故障处理程序中启用了中断时，得到了一个 ARM 内核 oops。

该问题与其他用户在此处报告的问题相似。但在我的情况下，当我向系统发送 110% 负载 UDP 数据包（系统丢弃大约 10% 数据包）时，内核会在几分钟内发生错误。仅当有一些busybox shell 脚本正在运行时才会发生这种情况，而不是仅当UDP 接收程序正在运行时才会发生。我跟踪了看起来总是不错的数据地址，缓冲区在释放之前已分配和使用。

有两种方法可以避免：

[1] 将调度从抢占 (CONFIG_PREEMPT) 更改为抢占自愿时，问题就消失了。这是内核 2.6.39 上 ARM 的一个已知问题吗？通过抢占调度，我在很长一段时间后也看到了 jffs2 的问题，但 preempt_volunt 没有。

有一瞬间我怀疑是以太网 DMA 充分利用了总线，从而阻止 CPU 加载其 TLB 条目，从而导致页面错误。我推断是因为busybox脚本需要在图片中，当一个脚本被生成时，它会创建地址空间并加载许多TLB条目，从而使总线超载。如果 preempt_volunte 是一个解决方案，是否可以排除 DMA 阻塞总线？

我正在运行的测试是基于 phy3250 的系统上的 LTIB 内核 2.6.39.4 lpclinux。

[2] 更多测试表明页面错误处理程序嵌套在以太网中断中。当在内核页面错误处理程序 __dabt_svc 中禁用中断，但在用户页面错误处理程序 __dabt_user 中保持启用时，问题就消失了。如果不是，则嵌套级别上升到 4 并且它 oops'ed。所以问题是：在页面错误处理程序中启用中断是否正确？

[2] 的测试代码如下。添加或修改带有@@@@ 的行。然后在 do_DataAbort() 中捕获嵌套级别。

并将变量也添加到文件中：

我正在尝试将所有这些联系起来。内核专家能否看到所有测试是否有意义？在页面错误处理程序中禁用中断是一个有效的解决方案吗？

编辑：页面错误处理程序中的 oops 不是第一次失败。正在进行的对齐处理程序中有一个“do_bad_area”。随后，对未对齐访问的修复失败导致页面错误。是的，正如下面有人评论的那样，修复未对齐的访问非常麻烦。那些未对齐的访问来自 ip_input、ip_fragment 和 udp 堆栈。一旦我修复了堆栈中的所有内容，问题就消失了。

再次编辑：问题在于对齐处理程序中的两个操作：它获取指令，并获取指令引用的数据。oops 由数据访问报告，但原因是获取指令失败，第一个页面错误失败。由于 fetch 指令在内核空间中，因此页面始终有效，这表明存在硅错误。如果更改代码以再次获取它会成功，这证实它更有可能是一个硅错误。中断进入画面是因为它带来了过多的 TLB 刷新。简而言之，TLB 加载是自动的，因此在内核空间中获取指令不会失败。但它仍然失败了。

我从williamstalling一书中学习，如果我们增加页面大小然后pagefault首先增加，然后当pagesize变成进程大小时pagefault减少，那么它就写在那里。我无法理解为什么页面错误会增加，就像我增加页面大小一样，请任何人解释原因。谢谢你。

我看到 netbsd 系统内核出现看门狗超时的问题，堆栈跟踪显示内核页面错误处理程序被软件中断中断以处理 ip 数据包，跟踪看起来像这样。这个netbsd 4.x

0xcf910db0：在 m_copyback0+0x3fc

0xcf910e00：在 m_makewritable+0x40

0xcf910e20：在 fr_check_wrapper+0x44

0xcf910e50：在 pfil_run_hooks+0xd0

0xcf910e90：在 ip_input+0x3dc

0xcf910ed0：在 ipintr+0x4c

0xcf910f00：在 netintr+0x60

0xcf910f20：在 softintr_dispatch+0x150

0xcf910f60：在 ext_intr+0x2bc

0xcf910fa0：在 cpu_switchto+0x768

0xf1733d90：在 uvm_fault_internal+0x150

我的问题是，在页面错误处理程序中启用中断是个好主意吗？

我使用 sigaction 来处理缺页异常，处理函数定义如下：

所以通过阅读info->si_addr很容易得到缺页地址。

问题是，如何知道这个操作是内存READ还是WRITE？

我发现_context参数的类型是在/usr/include/sys/ucontext.h中定义的ucontext_t

在mcontext_t中定义了一个 cr2 字段，但不幸的是，它仅在未定义x86_64时可用，因此我无法使用 cr2 来识别读/写操作。

另一方面，在 /usr/include/bits/sigcontext.h中定义了一个名为sigcontext的结构， 该结构包含cr2字段。但我不知道从哪里得到它。

在我用 C++ 编写的应用程序中，我得到了以下时间信息。

即使没有严重的页面错误，如此高的挂起时间可能是什么原因？

当我正在考虑进行网络寻呼（从远程节点请求错误页面）时，我得到了这个问题：

首先，让我们考虑以下步骤：

1) 用户空间程序尝试访问内存 X。

2）MMU遍历页表找到X的物理地址。

3) 遍历页表时，发现页表项无效。

4) CPU 陷阱并被 Linux 陷阱向量捕获。（在ARM的情况下，但我认为x86也是一样的，对吧？）

5）此时，我可以从远程节点检索适当的数据，复制到某个物理地址并将其映射到页表中。

6）问题来了：在这一点之后，在 X 处发生缺页的程序会安全地读取数据吗？那么，这是否意味着 MMU 或 CPU 以某种方式记住了缺页页表条目并返回到该条目并恢复页表的行走？

如果有任何步骤不对，请赐教。