Ich studiere für RHCSA und bin verwirrt über eine Aussage, die ich in einem Schulungsmaterial gefunden habe:

Es gibt kein praktisches maximales RAM, da Sie theoretisch 128 TB RAM auf RHEL 6 ausführen könnten. Aber das ist nur Theorie. Der von Red Hat unter RHEL 6 unterstützte maximale Arbeitsspeicher beträgt 16 GB auf 32-Bit-Systemen und 2 TB auf 64-Bit-Systemen.

Kann jemand bitte erklären, woher die theoretische Grenze von 128 TB kommt? Ich bin verwirrt darüber, woher der Autor weiß, dass die theoretische Grenze existiert, wenn RHEL 6 andere maximale Grenzen klar definiert. Berücksichtigt dies nur die theoretischen Grenzen der 64-Bit-Architektur? Oder gibt es hier einen anderen Grund?

Aus der Kerneldokumentation in Documentation/x86/x86_64/mm.txt:

Virtual memory map with 4 level page tables:

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

2 ⁴⁷ Bytes = 128 TiB

Kurze Antwort

Jeder Linux-Prozess kann höchstens 128 TB virtuellen Speicher adressieren . Dies ist jedoch mehr, als der Linux-Kernel physisch verarbeiten kann . Daher ist diese Grenze theoretisch.

Es wurde wahrscheinlich willkürlich ausgewählt, basierend auf einem vermeintlich vorhersehbaren "Worst-Case" -Nutzungsszenario.

Ausgearbeitete Antwort

Sie können nicht mehr RAM verwenden, als Ihre Hardware zulässt (48 Bit = 256 TB sind heutzutage üblich), und dann sind Sie durch die Menge an physischem Speicher begrenzt, die der Linux-Kernel verarbeiten kann.

In der 64-Bit- Architektur von Intel x86 kann Linux beispielsweise nicht mehr als 64 TB physischen Speicher verwenden (seit Version 2.6.30 , aber kurz zuvor waren es 16 TB ). Beachten Sie, dass RHEL 6 einen 2.6.32- Kernel verwendet.

Für die 64-Bit- s390-Architektur gilt das gleiche Limit (seit 2.6.28 ). Wenn Sie jedoch 32-Bit verwenden, beträgt das Limit 4 GB. Wenn Sie jedoch einen seltsamen Trick namens PAE verwenden , können Sie bis zu 64 GB verwenden (häufig unter x86 verwendet).

Ich denke, andere 64-Bit-Architekturen haben untere Grenzen.

Weitere Informationen finden Sie in der Red Hat- Grenzwerttabelle (danke Huygens ).

Man sollte virtuellen Speicher und physischen flüchtigen Speicher nicht verwechseln. Ersteres ist spezifisch für die CPU-Architektur und wird einem flüchtigen und einem nichtflüchtigen Speicher zugeordnet. Letzteres, auch bekannt als RAM, sollte aus Kernel-Sicht unabhängig von der CPU-Architektur sein.

Die heutige AMD- und Intel x86_64-Implementierung unterstützt nur 48 Bit adressierbaren virtuellen Speicher. Dies bedeutet, dass der Kernel 2 ^ 48 = 256 TiB pro Prozess-VM adressieren kann.
Der Linux-Kernel in der x86_64-Architektur teilt den adressierbaren VM-Speicherplatz in 2, 128 TiB für den Benutzerbereich und 128 TiB für den Kernelbereich auf. Ein Prozess kann also theoretisch insgesamt 128 TiB virtuellen Speicher adressieren.

Das Maximum des flüchtigen physischen Speichers, das der Kernel verarbeiten kann, ist ein anderer Aspekt, aber ich kenne diese Informationen nicht.

In Bezug auf die RHCSA-Autorenerklärung

Der Autor der Aussage "Es gibt kein praktisches maximales RAM, da theoretisch 128 TB RAM auf RHEL 6 ausgeführt werden könnten." verwendet eine falsche oder missverstandene Terminologie. In der folgenden Tabelle der Red Hat-Website sind die Funktionen von RHEL 3, 4, 5 und 6 zusammengefasst . Und sie geben eindeutig an: "Maximaler x86_64 virtueller Adressraum pro Prozess [...] 128 TB [für RHEL 6]".

Auf derselben Seite wird angegeben, dass RHEL 6 maximal 2 TB / 64 TB RAM (physischer flüchtiger Speicher) unterstützt. Ich denke, es bedeutet, dass es für maximal 2 TB RAM zertifiziert ist und theoretisch bis zu 64 TB erreichen kann. SLES ist in dieser Hinsicht viel klarer .

Der andere theoretische Grund ist der Mangel an Implementierungserfahrung.

Es ist üblich, dass Programmierer Variablen weit vor der Hardware-Größe dimensionieren, damit der Kernel keine riskante Rip-and-Replace-Programmierung benötigt, da Hardware dieser Fähigkeit ein Jahrzehnt oder später erscheint.

Die variable Größe ist jedoch nicht die einzige Grenze. Datenstrukturen und ihre Algorithmen setzen ihre eigenen Grenzen. Stellen Sie sich für einen Moment einen linearen Spaziergang durch eine Datenstruktur vor, die jede 4-KB-Seite dieser 128 TB beschreibt. Es gibt einige offensichtliche Antworten: Verwenden Sie keine 4-KB-Seiten, verwenden Sie keine lineare Datenstruktur, greifen Sie nicht häufig auf diese Datenstrukturen zu, und laden Sie so viel wie möglich in die Hardware. Es gibt jedoch subtilere Einschränkungen in Bezug auf Datenstruktur und Algorithmus, die wir erst kennen, wenn wir auf sie stoßen.

Wir wissen, wenn wir morgen auf magische Weise einen 128-TB-PC entdecken und versuchen, Linux darauf zu booten, wird er eine schreckliche Leistung erbringen und vielleicht so schrecklich, dass er nicht startet. Das Fixieren der Algorithmen ist jedoch trivial. Das Fixieren der Datenstrukturen ist etwas Arbeit, aber immer noch viel weniger Arbeit als das Fixieren der Größe einer weithin verstandenen Variablen. Wir werden also Änderungen dieser Art sehen, wenn die Speichergröße zunimmt.