1GBの巨大なページ-1GBのチャンクで書き込みが発生していますか？
巨大なページサイズと実際にデータがRAMに書き込まれる方法との関係を理解しようとしています。
プロセスが1GBの巨大なページを使用するとどうなりますか？書き込みは1GBのチャンクで行われますか？私はこの仮定に完全に間違っていると思いますか？
メモリ書き込みのチャンクサイズには複数の定義があります。あなたはそれを次のように考えることができます：
- ストアの幅 命令 （ストアバイト、ストアワード、…）、通常は1、2、4、8、または16。
- cache 行の幅。通常は16バイトまたは64バイトのようなものです（キャッシュレベルが異なれば、行幅も異なる場合があります）。
- メモリバス の幅。これはソフトウェアでは直接観察できません。
- そしておそらくいくつかのより合理的な感覚。
これらはいずれもページサイズに関連していません。
ページサイズは、 [〜＃〜] mmu [〜＃〜] のページの属性です。 MMUは 仮想アドレス （プログラムによって使用される）を 物理アドレス （メモリ内の物理的な場所を指定する）に変換します。変換するプロセス。仮想アドレスから物理アドレスへの変換は次のようになります。
- 第1レベル記述子テーブルのアドレスを検索します。
- 仮想アドレスの最上位ビットを抽出し、それらを第1レベルの記述子テーブルのインデックスとして使用します。
- そのインデックスでL1記述子をデコードします。これにより、第2レベルの記述子テーブルのアドレスが生成されます。
- 仮想アドレスからさらにビットを抽出し、それらを第2レベルの記述子テーブルのインデックスとして使用します。
- そのインデックスでL2記述子をデコードします。これにより、ページの開始アドレスが生成されます。ページは、物理的に隣接するメモリの単位であり、MMUテーブルの1つのエントリによって記述されます。
- 仮想アドレスの残りのビットをページ開始アドレスでマスクして、物理アドレスを取得します。
一般的な32ビットアーキテクチャは、2つのテーブルレベルを通過します。一般的な64ビットアーキテクチャは3を通過します。Linuxは最大4つのレベルをサポートします。
一部のCPUアーキテクチャは、一部のページを大きくし、間接化のレベルを少なくすることをサポートしています。これにより、アクセスが高速になり、ページテーブルのサイズが小さくなりますが、メモリ割り当ての柔軟性が低下します。時間の増加はほとんどのアプリケーションで最小限ですが、データベースなどの小さなページの柔軟性の恩恵を受けないパフォーマンスに敏感なアプリケーションでは感じることができます。 巨大なページは、通常の量よりも少ないレベルを通過し、それに応じて大きいページです。
大きなページを使用しているソフトウェアは、通常、それらを具体的に要求します（mmapへのフラグを介して、 仮想アドレス空間でページサイズはどのように決定されますか？ 詳細については）。この最初のリクエストの後、ページサイズを知ったり気にしたりする必要はありません。特に、メモリアクセスはMMUによって処理されます。アクセス時にはソフトウェアは関与しません。
巨大なページは、メモリのチャンクを割り当てるためのものであり、書き込むためのものではありません。
通常、アプリケーションが大量のメモリを必要とする場合、多くの「ページ」を割り当てる必要があります。ページは単に物理メモリのチャンクです。通常、このチャンクはわずか数KBです。そのため、アプリケーションが多くのページにまたがるメモリを大量に消費する操作を実行している場合、カーネルがそれらすべての仮想メモリページを物理メモリに変換する必要があるとコストがかかります。
これを最適化するために、カーネルは巨大なページを提供します。これは基本的にデフォルトのページサイズよりも大きい割り当てです。したがって、数千ページを割り当てる代わりに、数ページしか割り当てられません。読み取りと書き込みは、読み取りまたは書き込みのサイズに関係なく行われます。アプリケーションが10バイトの文字列を巨大なページに書き込む場合でも、10バイトの書き込みになります。