問題タブ [page-fault]

アプリケーションの 1 つを Java で調整しようとしています。私は JAVA-Profiler を使用しており、そこからいくつかのレポートを取得しました。アプリケーションのページ フォールトの数が 30000 ～ 35000 の範囲であることがわかりました。この数値が高すぎるか正常かを判断するにはどうすればよいですか? 最初の 1 分間と 30 分後も同じデータを取得しています。

私の RAM は 2 GB で、アプリケーションをシングル スレッドで使用しています。

スレッドは 3 秒ごとにキューからメッセージを読み取ろうとしており、キューは空です。

なんの処理もしていないので、ページフォルトは一切発生しないはずだと思います。ここに案内してください。

ページ フォールトの原因となるメモリ アクセス (ポインタ) を取得する方法を知っている人はいますか? 私は主に主要なページフォールトに興味があります。

私が達成しようとしていることについての少しの背景。大きなメモリ フットプリント (データベース) を持つアプリケーションがあり、ページングを大きなデータ構造 (テーブル、mmap() を使用して割り当てられたインデックスなど) へのアクセスと関連付けたいと考えています。プロセスのマッピングは、/proc//maps から簡単に取得できます。ここで、ページ フォールトを引き起こすメモリ アクセスがある場合、各データ構造にアクセスするときに発生したページ フォールトの数を追跡できます。

perf または systemtap で十分だと思います。何か案は？

私は本のウィリアムストールから学びました。そこに書かれているのは、ページのサイズを大きくすると最初にページフォールトが増加し、次にページサイズがプロセスのサイズになるとページフォールトが減少するということです。ページサイズを増やしたかのようにページフォールトが増加する理由を理解できません。理由を説明してください。ありがとうございました。

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 がページ フォールトのページ テーブル エントリを何らかの形で記憶し、そのエントリに戻ってデータを再開することを意味しますか?ページテーブルのウォーキング？

手順のいずれかが正しくない場合は、教えてください。