20

最新の x86 CPU は、従来の 4K (つまり 2MB または 4MB) よりも大きなページ サイズをサポートする機能を備えており、この機能にアクセスするための OS 機能 ( Linux、Windows ) があります。

上記のマイクロソフトのリンクでは、大きなページは「変換バッファの効率を高め、頻繁にアクセスされるメモリのパフォーマンスを向上させることができます」と述べています。大きなページが特定の状況を改善するかどうかを予測するには、これはあまり役に立ちません。一部のプログラム ロジック (またはアプリケーション全体) を移動してヒュージ ページを使用することでパフォーマンスが改善された具体的な、できれば定量化された例に興味があります。サクセスストーリーはありますか？

私が知っている特定のケースが 1 つあります。巨大なページを使用すると、大きなプロセスを fork するのに必要な時間が劇的に短縮されます (おそらく、コピーが必要な TLB レコードの数が 1000 分の 1 に減少するため)。それほどエキゾチックではないシナリオでも、巨大なページがメリットになるかどうかに興味があります。

4

5 に答える 5

18

パフォーマンスの最大の違いは、メモリの広い領域に広い間隔でランダム アクセスを行う場合に発生します。ここで「大きい」とは、TLB 内のすべての小さなページ エントリによってマップできる範囲よりもはるかに大きいことを意味します (通常は最新のプロセッサでは複数のレベルがあります)。

さらに複雑なことに、4kB ページの TLB エントリ数は 2MB ページのエントリ数よりも多くなることがよくありますが、これはプロセッサによって大きく異なります。レベル 2 TLB で使用可能な「ラージ ページ」エントリの数にも、さまざまなバリエーションがあります。

たとえば、AMD Opteron ファミリ 10h リビジョン D (「イスタンブール」) システムでは、cpuid は次のように報告します。

  • L1 DTLB: 4kB ページ: 48 エントリ。2MB ページ: 48 エントリ。1GB ページ: 48 エントリ
  • L2 TLB: 4kB ページ: 512 エントリ。2MB ページ: 128 エントリ。1GB ページ: 16 エントリ

Intel Xeon 56xx (「Westmere」) システムでは、cpuid は次のように報告します。

  • L1 DTLB: 4kB ページ: 64 エントリ。2MB ページ: 32 エントリ
  • L2 TLB: 4kB ページ: 512 エントリ。2MB ページ: なし

どちらもレベル 2 TLB ミスが発生する前に小さなページを使用して 2MB (512*4kB) をマップできますが、Westmere システムは 32 個の 2MB TLB エントリを使用して 64MB をマップでき、AMD システムは L1 および L2 で 176 個の 2MB TLB エントリを使用して 352MB をマップできます。 TLB。いずれのシステムも、2MB よりはるかに大きく 64MB 未満のメモリ範囲でのランダム アクセスにラージ ページを使用することで、大幅なスピードアップが得られます。AMD システムは、はるかに大きなメモリ範囲に対して大きなページを使用して、引き続き優れたパフォーマンスを発揮するはずです。

これらすべてのケースで回避しようとしているのは、x86_64 階層アドレス変換の 4 つのレベルすべてをトラバースするという最悪のケース (注 1) のシナリオです。
アドレス変換キャッシング メカニズム (注 2) が機能しない場合は、次のものが必要です。

  • 4kB ページにマップされたデータをロードするためのメモリへの 5 回のトリップ、
  • 2MB ページにマップされたデータをロードするためのメモリへの 4 回のトリップ、および
  • 1GB ページにマップされたデータをロードするためにメモリに 3 回トリップします。

いずれの場合も、メモリへの最後のトリップは要求されたデータを取得することであり、他のトリップはページ変換情報のさまざまな部分を取得するために必要です。私が見た中で最も適切な説明は、AMD の「AMD64 Architecture Programmer's Manual Volume 2: System Programming」(出版物 24593) http://support.amd.com/us/Embedded_TechDocs/24593.pdfのセクション 5.3 にあります。

注 1: 上記の数値は実際には最悪のケースではありません。仮想マシンで実行すると、これらの数値が悪化します。さまざまなレベルのページ テーブルを保持するメモリがディスクにスワップされる環境で実行すると、パフォーマンスが大幅に低下します。

注 2: 残念ながら、このレベルの詳細を知るだけでは十分ではありません。最近のすべてのプロセッサには、ページ変換階層の上位レベルに追加のキャッシュがあるためです。私が知る限り、これらは公に文書化されていません。

于 2012-03-12T21:20:05.067 に答える
11

大きなページから得られる利益を調べるために、4k ページで TLB のスラッシングを最大化するコードを考案しようとしました。libhugetlbfs の malloc (Intel i7、64 ビット Debian Lenny ) によって 2MByte ページが提供される場合、以下のものは(4K ページよりも) 2.6 倍速く実行されます。うまくいけば、何をして何をするのかが明らかにscoped_timerなりrandom0nます。

  volatile char force_result;

  const size_t mb=512;
  const size_t stride=4096;
  std::vector<char> src(mb<<20,0xff);
  std::vector<size_t> idx;
  for (size_t i=0;i<src.size();i+=stride) idx.push_back(i);
  random0n r0n(/*seed=*/23);
  std::random_shuffle(idx.begin(),idx.end(),r0n);

  {
    scoped_timer t
      ("TLB thrash random",mb/static_cast<float>(stride),"MegaAccess");
    char hash=0;
    for (size_t i=0;i<idx.size();++i) 
      hash=(hash^src[idx[i]]);
    force_result=hash;
  }

大きなページからわずか 16% しか得られなかった単純な「直線」バージョンhash=hash^src[i]ですが、(勝手な憶測)アクセスが予測可能な 4K ケースでは、 Intel のファンシーなプリフェッチ ハードウェアが役立っている可能性があります (プリフェッチを無効にして、それが本当かどうかを調べることができると思います)。

于 2010-05-21T18:43:03.887 に答える
3

一部の HPC/Grid シナリオで改善が見られました。具体的には、大量の RAM を搭載したマシンで非常に大きなモデルを使用する物理パッケージです。また、モデルを実行しているプロセスだけがマシン上でアクティブでした。測定はしていませんが、特定の DB 機能 (一括インポートなど) も同様に役立つと思います。

個人的には、十分にプロファイリングされた/理解されたメモリ アクセス プロファイルがあり、大量のメモリ アクセスを頻繁に行わない限り、大幅な改善は見られないと思います。

于 2010-05-20T20:49:11.997 に答える
3

これは難解ですが、Huge TLB ページは、Intel Xeon Phi (MIC) アーキテクチャで DMA メモリ転送 (ホストから PCIe 経由の Phi へ) を行うときに大きな違いをもたらします。この Intel リンクでは、ヒュージ ページを有効にする方法について説明しています。通常の TLB ページ サイズ (4K) で 8 MB を超えて DMA 転送サイズを増やすと、パフォーマンスが低下し始め、転送サイズが 512 MB に達すると、約 3 GB/秒から 1 GB/秒未満になることがわかりました。

巨大な TLB ページ (2MB) を有効にした後、データ レートは増加し続け、512 MB の DMA 転送で 5 GB/s を超えました。

于 2014-10-15T23:46:30.420 に答える
2

大きなプロセスを実行する大量のメモリ (>=64GB) を備えたサーバーでは、最大 5% の速度向上が得られます。たとえば、16GB の Java プロセスの場合、4M x 4kB ページですが、4k x 4MB ページしかありません。

于 2010-05-21T07:23:01.737 に答える