私はRHCSAのために勉強していて、いくつかのトレーニング資料で出くわした言葉に混乱しています：

理論的には、RHEL 6で128 TBのRAMを実行できるので、実用的な最大RAMはありませんが、それは単なる理論です。RHEL 6上のRed Hatがサポートする最大RAMは、32ビットシステムでは16 GB、64ビットシステムでは2 TBです。

128 TBの理論上の制限がどこから来ているのか誰かが説明できますか？RHEL 6が他の最大制限を明確に定義している場合、著者が理論上の制限が存在することをどのようにして知るかについて、私は混乱しています。これは64ビットアーキテクチャの理論上の制限を考慮に入れているだけですか？それともここに他の理由がありますか？

カーネルのドキュメントからDocumentation/x86/x86_64/mm.txt：

Virtual memory map with 4 level page tables:

0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm

2 ⁴⁷バイト= 128TiB

簡潔な答え

各Linuxプロセスは、最大128 TBの仮想メモリをアドレス指定できます。ただし、これはLinuxカーネルが物理的に処理できる以上のものです。したがって、この制限は理論上のものです。

これはおそらく、想定可能な「最悪の場合」の使用シナリオに基づいて、任意に選択されたものです。

精巧な答え

ハードウェアで許可されている以上のRAMを実際に使用することはできません（48ビット= 256 TB が最近一般的です）。その場合、Linuxカーネルが処理できる物理メモリの量によって制限されます。

たとえば、Intel x86 64ビットアーキテクチャでは、Linuxは64 TBを超える物理メモリを使用できません（バージョン2.6.30以降、ただし直前は 16 TB でした）。RHEL 6は2.6.32カーネルを使用することに注意してください。

64ビットs390アーキテクチャでは、同じ制限が適用されます（2.6.28以降）。ただし、32ビットを使用する場合、制限は4 GBですが、PAEと呼ばれる奇妙なトリックを使用すると、最大64 GB（x86でよく使用されます）になる場合があります。

他の64ビットアーキテクチャには下限があると思います。

詳細については、Red Hatの制限の表を参照してください（Huygensに感謝）。

仮想メモリと物理揮発性メモリを混同しないでください。前者はCPUアーキテクチャ固有であり、揮発性メモリと不揮発性メモリにマップされます。後者（別名RAM）は、カーネルの観点からはCPUアーキテクチャーから独立している必要があります。

現在のAMDおよびIntel x86_64実装は、 48ビットのアドレス可能な仮想メモリのみをサポートしています。これは、カーネルがプロセスVMあたり2 ^ 48 = 256 TiBに対応できることを意味します。
x86_64アーキテクチャ上のLinuxカーネルは、アドレス可能なVM空間を2つに分割しました。ユーザー空間用に128 TiB、カーネル空間用に128 TiBです。したがって、プロセスは理論上、合計で128 TiBの仮想メモリに対応できます。

カーネルが処理できる揮発性物理メモリの最大値は別の側面ですが、私はこの情報を知りません。

RHCSA著者の声明について

「理論的には、RHEL 6で128 TBのRAMを実行することができるので、実用的な最大RAMはありません。」間違ったまたは誤解された用語を使用しています。以下は、RHEL 3、4、5、6の機能をまとめたRed Hat Webサイトの表です。また、「プロセスごとの最大x86_64仮想アドレス空間[...] 128TB [RHEL 6の場合]」と明確に述べています

同じページには、RHEL 6が最大2 TB / 64 TBのRAM（物理揮発性メモリ）をサポートすることが記載されています。最大2 TBのRAMで認定されており、理論的には最大64 TBに達する可能性があることを意味します。SLESはこの点ではるかに明確です。

それが理論的であるもう1つの理由は、実装経験の欠如です。

プログラマーは、ハードウェアで可能な機能よりもはるかに前に変数のサイズを決定するのが一般的です。そのため、その機能のハードウェアが10年以上後に出現しても、カーネルは危険なリップアンド置換プログラミングを必要としません。

ただし、可変サイズだけが制限ではありません。データ構造とそのアルゴリズムには独自の制限があります。その128TBの各4KBページを記述するデータ構造の線形ウォークを行っていると想像してみてください。明らかな対応がいくつかあります。4KBページを使用しないでください。線形データ構造を使用しないでください。これらのデータ構造に頻繁にアクセスしないでください。できるだけハードウェアにオフロードしてください。しかし、さらに微妙なデータ構造+アルゴリズムの制限があり、それらに遭遇するまで知りません。

明日、128 TBのPCを魔法のように発見してLinuxを起動しようとすると、それは恐ろしく、恐らく起動できないほど恐ろしく実行されます。しかし、アルゴリズムを修正することは簡単です。データ構造を修正することはいくらかの作業ですが、広く理解されている変数のサイズを修正するよりもはるかに少ない作業です。したがって、メモリサイズが大きくなるにつれて、その性質の変化がわかります。