Warum haben 32-Bit-Prozesse ein RAM-Limit von 2 GB?

4159
pfedotovsky

Ich bin gespannt, warum es bei 32-Bit-Betriebssystemen ein Limit von 2 GB für einen 32-Bit-Prozess gibt. Laut dem Blogeintrag Chat-Frage: Speicherlimits für 32-Bit- und 64-Bit-Prozesse kann der Grenzwert auf 3 GB erweitert werden, die Frage bleibt jedoch bestehen.

Ich sehe, dass die physische Grenze 4 GB beträgt, also sind 2 oder 3 GB in Windows nur fest codiert? Warum nicht 4 GB als 32-Bit-Prozess auf einem 64-Bit-Betriebssystem haben?

HINWEIS: Diese Frage wurde als Duplikat markiert, die referenzierte Frage bezieht sich jedoch auf die Beschränkung von 4 GB des 32-Bit-Adressraums. Das frage ich NICHT . Ich frage speziell, warum Windows Prozesse auf 2 GB begrenzt - sogar auf einer 32-Bit-Plattform. Die akzeptierte Antwort erwähnt es, erklärt aber nicht warum.

5
"Warum nicht 4 GB als 32-Bit-Prozess unter 64-Bit-Betriebssystemen haben?" - Microsoft hat sich für diese Einschränkung entschieden. "Ich sehe, dass die physische Grenze bei 4 GB liegt, also sind 2 oder 3 GB in Windows nur fest codiert?" - Ja Ramhound vor 7 Jahren 0
32-Bit-Fenster ordnen dem Prozess 2 GB Kernelspeicher zu, um Operationen zu beschleunigen. Für den Prozess stehen also nur 2 GB zur Verfügung. Lesen Sie das nächste Windows Internals-Buch, das dort ausführlich erläutert wird magicandre1981 vor 7 Jahren 0
Kurze Antwort: Leistung. Wenn Sie jedem Prozess einen Adressraum von 4 GB zuweisen, wäre für die Systemnutzung ein separater Adressraum erforderlich. Das Wechseln von Adressräumen, ein Kontextwechsel, verursacht einen erheblichen Leistungsaufwand. Viele Anwendungen führen häufig Betriebssystemaufrufe durch, die Zugriff auf den Systemadressraum erfordern, und Systemunterbrechungen erfordern dies ebenfalls. Durch die Begrenzung des Prozessadressenbereichs auf 2 GB kann er mit einem Systemadressraum von 2 GB koexistieren und diese häufigen Kontextwechsel vermeiden. Beachten Sie, dass jeder Prozess über einen eigenen Adressraum von 2 GB verfügt, der nicht mit anderen geteilt wird. LMiller7 vor 7 Jahren 0

2 Antworten auf die Frage

6
LMiller7

Auf der NT-Plattform ist der virtuelle Adressraum von 4 GB standardmäßig in zwei Teile unterteilt, die unteren 2 GB für Prozessadressen und die oberen 2 GB für die Systemnutzung.

Dieser Adressraum ist virtuell und wird nicht durch die RAM-Größe beeinflusst. Der CPU- und OS-Speichermanager ordnet bei Bedarf RAM-Bereiche in den virtuellen Adressraum ein. Dies ist sehr komplex und wird hier nicht beschrieben. Dies war eine Design-Entscheidung, die im Hinblick auf Leistung, Sicherheit und Zuverlässigkeit getroffen wurde.

Jeder Prozess verfügt über einen eigenen privaten Adressraum von 2 GB, es gibt jedoch nur einen Systemadressraum. Prozesse werden in ihrem eigenen privaten Adressraum isoliert und können andere nicht einmal sehen. Es ist vorgesehen, bei Bedarf die Adresse zwischen zwei oder mehr Prozessen zu teilen. Der Systemadressraum ist für normale Prozesse gesperrt und nur für Kernel-Komponenten wie das Betriebssystem selbst und Gerätetreiber zugänglich. Wenn ein Prozess in die Irre geht, kann er sich nur selbst verletzen. andere Prozesse und das Betriebssystem sind davon nicht betroffen.

Aber warum nicht dem System einen eigenen privaten Adressraum geben, genau wie bei Prozessen? Dadurch könnte der gesamte Adressraum von 4 GB für das System und die einzelnen Prozesse verfügbar sein. Das hätte getan werden können - aber es gab ein Problem.

Angenommen, das wurde getan. Der laufende Prozess hätte vollen Zugriff auf seinen eigenen Code und seine eigenen Daten und alles scheint gut zu sein. Was aber, wenn dieser Prozess einen Betriebssystemaufruf ausführt, der Zugriff auf den Systemadressraum erfordert, z. B. für einen E / A-Vorgang? Oder was passiert, wenn ein Interrupt vom Kernel verarbeitet werden muss?

Nur der Adressraum des laufenden Prozesses ist für die CPU sichtbar. Was ist zu tun? Die Lösung besteht darin, einen Kontextwechsel durchzuführen, der den Systemadressraum in Sicht bringt. Das Betriebssystem kann dies ziemlich effizient, aber es braucht Zeit. Wenn häufig auf den Systemadressraum zugegriffen werden muss, wäre der Aufwand für Kontextwechsel zu groß und die Leistung wird beeinträchtigt.

Es musste einen besseren Weg geben.

Die Lösung bestand darin, den gesamten Adressraum von 4 GB in zwei Teile von jeweils 2 GB zu unterteilen. Bearbeiten Sie den Adressraum in den unteren 2 GB und das System in den oberen. Dadurch kann der Systemadressraum immer im Gültigkeitsbereich sein und jederzeit ohne Kontextwechsel verfügbar sein. Designentscheidungen werden häufig aus praktischen Gründen getroffen.

2 GB scheinen jetzt sehr klein und restriktiv zu sein, aber es war riesig, als NT 1993 veröffentlicht wurde. Und vergessen Sie nicht, dass jeder Prozess seine eigenen 2 GB hat.

Ich habe Schwierigkeiten, das zu verstehen. Sie scheinen zu sagen, dass der Kernelspeicher oder der gesamte Kernelspeicher und möglicherweise die Adressen von E / A-Geräten mit Speicherzuordnung immer im virtuellen Adressraum liegen, dh auch wenn der Benutzercode ausgeführt wird. Wenn ja, kann der Benutzerprozess darauf zugreifen? Wenn dies der Fall ist, wäre dies offensichtlich ein schwerwiegender Sicherheitsfehler. Kannst du das erklären? Scott vor 7 Jahren 0
Der gesamte Kernelspeicher befindet sich jederzeit im 4-GB-Prozessadressraum, auch wenn der Benutzercode ausgeführt wird. Aber nur der Code auf Kernel-Ebene hat Zugriff darauf. Jeder Versuch, durch einen Prozess auf Benutzerebene auf den Kernelspeicher zuzugreifen, schlägt mit einer Ausnahme fehl. Speicherzugewiesene Hardwaregeräte werden unterschiedlich verwaltet (ich kenne die Details nicht), aber sie können auch nicht auf Benutzercode zugreifen. Ein Prozess auf Benutzerebene kann nur seinen eigenen Code und seine eigenen Daten sehen. Es ist vorgesehen, Code und Daten zwischen mehreren Prozessen gemeinsam zu nutzen. LMiller7 vor 7 Jahren 1
3
blami

Laut Windows Internals war es eine Entwurfsentscheidung. Sie teilen den gesamten virtuellen Speicher von 4 GB in zwei Teile auf:

  • Virtueller Adressraum im Kernelmodus mit 2 GB (Treiberspeicherfenster usw.)
  • Virtueller Adressraum mit 2 GB Benutzermodus (Speicher für Benutzerbereichsprogramme)

Dann gibt es den nicht empfohlenen /3GBSchalter (der den Kernel 1: 3-Benutzer ändert und zu bösen Fehlern bei Treibern führen kann, die absolute Versätze zuweisen), PAE und ich glaube, dass es eine weitere API gab, die bei Verwendung die Zuweisung von nicht ausgelagertem Speicher ermöglicht Fenster dynamisch in den Adressraum der Programme (aber ich kann mich leider nicht an den Namen erinnern).

Übernehmen Sie diese Antwort über die Ziellinie, indem Sie sie explizit an Prozesse binden (wie verhält sich ein Prozess zum Kernel-Adressraum und zum Benutzer-Adressraum?). :-) fixer1234 vor 7 Jahren 0