32ビットカーネルの場合、PAEと非PAEの長所/短所は何ですか？

Ubuntu 12.04 32ビットを使用しています。私のカーネルはPAEカーネルです。これらは、4 GBのRAMをすべて備えた32ビットOSで使用できるカーネルであり、4 GBのすべてのRAMを利用できます。

私のシステムは32ビットシステムです。だから私はそれらは必要ないと思った。PAEカーネルを実行し続けると、どのような長所と短所がありますか？

raja@badfox:~$ uname -a
Linux badfox 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012 i686 i686 i386 GNU/Linux

— rɑːdʒɑ
ソース

PAEを使用すると、32ビットシステムで3.2GBを超えるRAMを使用できます。RAMが少ない場合、または64ビットシステムの場合は、必要ありません。私はそれに問題がないことを知っています。

— Marty Fried

@EliahKagan私のシステムは32ビット、OSは32ビットですが、カーネルPAEです。したがって、PAEカーネルを使用し続けると、PAEカーネルの利点と欠点は何ですか。

— rɑːdʒɑ

主な問題はこれです：あなたのシステムにはどれくらいのRAMがありますか？PAEの利点は、32ビットOSで3.2GBを超えるRAMにアクセスできることです。それが存在の理由です。64ビットOSはすでにはるかに多くのメモリにアクセスできるため、何もする必要はありません。

— Marty Fried

@EliahKagan：ありがとうございます。でも、おそらくizxの答えは、私が書くことができるものをすべて隠してしまうと思います。:)私はそれが答えでなかったので、もしあったとしても、デメリットが何であるかをはっきりとは知りませんでした。しかし、あなたはこの場合の簡単な答えが最善かもしれないということは正しいかもしれません。

— Marty Fried

回答:

短い答え：可能であれば64ビット版に移行します。これは、PAE / PAE以外の32ビット版よりも高速です。できない場合、非PAEはPAEよりも1〜2％速くなる可能性があります。

理論的には、PAEは非PAEに比べてわずかなオーバーヘッドがあります...

PAEの大きな利点は、32ビットプロセッサ/システムが4GB以上のRAMを使用できることです。
ただし、これには非PAEよりも若干多くのオーバーヘッドが必要であり、パフォーマンスがわずかに低下する可能性があります。
- これは非常に簡単な説明です。非PAEモードでは、32ビットCPUは2つのテーブルを検索（アクセス）して物理メモリアドレスにアクセスする必要があります。PAEモードでは、3つのテーブルを検索する必要があります。1つの追加のルックアップでは、いくつかの（非常に短い）追加時間が必要になるため、追加のオーバーヘッドが発生します。
- この回答の最後に、上記のポイントを説明するWikipedia PAE記事の 2つの画像があります。
- NX / XDビット：PAEカーネルは、64ビットプロセッサのNo-eXecute / eXecute-Disableビットもサポートしています。これは、ある種のウイルス/悪意のある攻撃（バッファオーバーフロー）を防ぐのに役立ちますが、IMOこれは、Ubuntuに32ビットカーネルを選択する場合にはそれほど重要ではありません。

...しかし、実際にはこのオーバーヘッドは無視できます（ほとんど何もありません）...

Phoronixは、4 GB以下のシステムでは、PAEカーネルが非PAEカーネルよりも最大で約5％遅くなる可能性があることを示す、長年にわたって多くのテストを行ってきました。これは特定のテストアプリケーション専用です。通常の差は1％未満です。
- 12.04 LTSのテスト-8 GBシステム！
- 11.04-4および8GBシステムのテスト

64ビットは、ほとんどの場合、32ビットカーネルの両方を上回ります。

上記のPhoronixベンチマークからわかることの1つは、RAMが4 GB未満の場合でも、64ビットが優れていることです（ただし、最低でも1 GBをお勧めします）。
64ビットプロセッサ（通常、Intel Atomsを除く2006年以降のプロセッサ）を使用している場合は、32ビットカーネルを使用するとパフォーマンスが低下する可能性があります。

非PAEとPAEページテーブルアクセスの比較：

非PAE
PAE

— Hは
ソース

では、RAMが4GB未満の場合、64ビットの方が32ビットよりも速いとお考えですか？何故ですか？また、まだ変換されていないか、変換にバグがある32ビットソフトウェアとの互換性の問題について言及していません。これは問題だと思いますか？それはそうだったようですが、おそらくこれは過去のものです。

— Marty Fried

もちろん、上記のコメントには考えるべきポイントがあります。

— rɑːdʒɑ

@MartyFriedコンパイラーは64ビットのほうが処理が優れているため、64ビットの方が32ビットよりも高速な場合があります。詳細を覚えていないので、それを拡張できる人がいるかもしれませんが、プログラムが割り当てることができる連続メモリの最大チャンク（2GiB / 4Gibをはるかに下回る）に関係していると思います。

— Eliah Kagan

その他の留意点は次のとおりです。（1）AMD64 / EM64T命令セットに追加された命令を使用するため、64ビットの方が高速である可能性があります（32ビットでは、多くのプログラムはせいぜい最低の共通分母にコンパイルされます）、i686）、および（2）RAMのメモリとディスクにスワップされたメモリの両方が各プログラムの仮想メモリ空間の一部であり、その仮想メモリ空間がアドレス指定されるため、RAMが4 GiBをかなり下回るマシンでは64ビットの方が高速かもしれません32ビットシステムでは32ビットポインター、64ビットシステムでは64ビットポインター。Pehraps izxはこれらの問題のいくつかについて話すことができます。

— Eliah Kagan

@EliahKagan：このQは正規のQの良い候補になると思いますか：「64ビットプロセッサを搭載していますが、RAMが4 GB未満です。3つのカーネルのうちどれを選択すればよいですか？」

— ish

いくつかの実際のデータについて、AtomベースのネットブックとSandybridgeベースのラップトップにi386、i386-pae、amd64をインストールするために収集したいくつかのベンチマークを以下に示します。

http://kernel.ubuntu.com/~cking/power-benchmarking/blueprint-foundations-p-64bit-by-default/hpmini-and-x220-tests/results-3/results.txt

..長所と短所にいくつかの洞察を与えるかもしれません。

— コリン・イアン・キング
ソース

特定のソフトウェア（zfsファイルシステム）で32ビット12.04を使用して深刻な問題が発生し、32ビットシステムのvmalloc制限を明らかにしました（paeとnon-paeの両方、およびvmallocとdepmodのparamsチューニングを試してみましたが...成功）。これはおそらく特殊なケースですが、例として挙げることができます。32ビットカーネル内部のどこかでの制限は、最大3.2 GBまで使用可能であっても、1 GBです。

可能であれば64ビット版を使用してください。Tou vcanは確かだと思います...これまでのところ、それ（= 64ビットCPUコア）は、実行中のほとんどすべてのシステムでサポートされているはずです。後の「アップグレード」はどうやら不安です（実際、dpkgと/ etc /と/ home /のコピーが新しいインストールの実行に役立つ場合でも、再インストールを意味します）。何らかの理由で古い/クローズドソースの32ビットアプリケーションまたは一部のライブラリを使用せざるを得ない場合でも、64ビットを恐れることは問題ないと思います。

— コロ
ソース