Kernel-Modus Speichergröße für ein x86 LARGEADDRESSAWARE-Programm auf einem x64-Computer?

Question

Der Titel fasst es ziemlich zusammen. Ich habe eine Anwendung kompiliert für x86-Plattformen, die das /largeaddressaware Flag gesetzt hat. Wenn ich es auf einem x64-System laufe, bekomme ich den erweiterten virtuellen 4-Gb-Benutzermodus-Speicher "kostenlos", ohne die Bootoption /3GB angeben zu müssen. Auf einem x86-System würde dies bedeuten, dass der Kernel-Modus-Speicher nur 1 GB wäre, aber da x64-Systeme mehr Speicher adressieren können, behält der Kernel-Modus die 2 GB bei oder wird sogar auf 3 GB angehoben?

Edit: Um klar zu sein, frage ich mich über Pro-Prozess-Grenzen. Die Frage ergibt sich aus dem Lesen this article.

Edit 2: Diese Frage ist kein Duplikat von How much memory can a 32 bit process access on a 64 bit operating system?, da diese Frage nur den durch die Anwendung zugänglichen Speicher adressiert, nicht den zugreifbaren Systemspeicher. Wenn ich falsch verstanden habe und für jeden Prozess keine Speicherkapazität für das System reserviert ist, würde ich es begrüßen, wenn jemand das als Antwort schreiben könnte. Ich bin mir sicher, dass ich nicht der erste bin, der darüber verwirrt ist.

Answer 1

Es gibt ein paar Missverständnisse, die Sie verwirren.

Betrachten wir zuerst 32-Bit-Windows. Der virtuelle Adressraum für jeden Prozess hat einen bestimmten Teil, der dem Prozess selbst zugewiesen ist, und einen bestimmten Teil für den Kernel, den er benötigt. Alle Prozesse teilen sich jedoch den gleichen Kernel-Speicher - die Tatsache, dass Sie sogar Kernel-Speicher in Ihrem eigenen virtuellen Adressraum haben, ist im Grunde eine Leistungsoptimierung, um Adressräume bei Kernel-Objekten und Daten in Ihrer Anwendung nicht wechseln zu müssen.

Standardmäßig ist dies eine 1: 1-Aufteilung, Sie erhalten also 2 GiB Benutzeradressraum und 2 GiB Kerneladressraum. Dies wurde (ab) von früher 32-Bit-Windows-Software (wenn Ihr Computer möglicherweise nur 4 MiB Speicher insgesamt mit einer 486-CPU oder ähnliches hatte) verwendet, weil aufgrund der Art und Weise der Speicher angelegt wurde, Ihre Benutzeradresse Raum hatte nie Zeiger über die 2 GiB Barrieren - effektiv geben Sie das höchste Bit eines beliebigen Pointers frei für Ihre eigenen Daten. Oft wurde dies verwendet, um eine hybride "Wenn es passt, dies ist ein Wert, sonst ist es ein Zeiger auf eine Struktur" -Ansatz zu ermöglichen, spart Speicher und ein wenig Indirektion. Da dies so weit verbreitet ist, war die Standardeinstellung die gleiche Aufteilung wie in den frühen Tagen, um Kompatibilitätsprobleme zu vermeiden. Sie haben jedoch auch die Möglichkeit, sich für eine andere Aufteilung zu entscheiden - 3 GiB User Space und 1 GiB Kernel Space. Dies ist, was die Option /3GB tut. Aber das ist nicht genug - Ihre Anwendung muss auch opt-in mit /LARGEADDRESSAWARE. Das sagt im Grunde "Ich mache keine komischen Sachen mit meinen Zeigern".

Es sollte beachtet werden, dass 32-Bit-OS oder Prozess bedeutet nicht unbedingt, dass Sie nur 4 GiB Speicher adressieren können - es beschränkt nur, was für die CPU an jedem Punkt direkt zugänglich ist. Für speicherintensive Server-Software können sogar die "32-Bit" -Versionen Unterstützung für die Adressierung von viel mehr Speicher bieten - zum Beispiel unterstützt der 32-Bit-MS-SQL-Server bis zu 64 GiB über AWE. Dies ist im Grunde eine weitere Virtualisierungsebene, die eine Neuzuordnung der physischen Adressen der virtuellen Adresse ermöglicht. Theoretisch gibt es keine Begrenzung für die Speicherkapazität, die Sie mit oder ohne AWE erreichen können - schließlich hindert Sie nichts daran, Ihre eigene Hardware zu haben, die als speicherabgebildete Datei fungiert und Ihnen somit unbegrenzten Adressraum bietet. Natürlich, wie die Tage der segmentierten Speicher, ist es nicht sehr einfach zu arbeiten oder praktisch :)

Auf 64-Bit-Windows macht die /3GB keinen Sinn mehr und wird ignoriert. Die standardmäßige Adressraumaufteilung hängt von der genauen Windows-Version ab, liegt jedoch im Bereich von "Terabyte und mehr", also weit außerhalb der 32-Bit-Grenzen. Für moderne Windows ist dies in der Regel 128 TiB User + 128 TiB Kernel. 32-Bit-Anwendungen müssen weiterhin wie zuvor /LARGEADDRESSAWARE verwenden.Da der Kernel jedoch jetzt 64-Bit ist, kann er sich nicht im selben Adressraum wie der Benutzerprozess befinden, sodass eine 32-Bit-Anwendung auf einem 64-Bit-Betriebssystem vollen Zugriff auf die 4 GiB Adressraum hat.

Natürlich sind diese Grenzen immer noch weit unter dem, was 64-Bit theoretisch adressierbar ist. Allerdings können die meisten 64-Bit-CPUs nicht den gesamten 64-Bit-Adressraum adressieren - das üblichste beim letzten Mal, das ich überprüfte, war nur 48-Bit. Und Überraschung, Überraschung - das gibt Ihnen 256 TiB Adressraum, das Limit in Windows. Nicht eine Microsoft Verschwörung schließlich! :) Das ist eigentlich nichts Neues. Die Tatsache, dass die 32-Bit-ALU von Intel x86 mit einem 32-Bit-Adressraum verknüpft ist, ist ein Ausreißer im CPU-Verlauf - CPUs haben oft entweder einen höheren oder niedrigeren Adressraum (für virtuelle Adressierung oder physikalische Adressierung) als ihre ALU-Breite . Die MS-DOS-typische Grenze von 1 MiB an adressierbarem Speicher (mit 640 kiB, die den Benutzeranwendungen überlassen werden) kommt davon ebenfalls - die "32-Bit" -Zyklen der Zeit konnten nur 20-Bit-Adressen verwenden.

Answer 2

Wie in dem Artikel beschrieben, auf den Sie verweisen, ist der auf einer 32-Bit-CPU verfügbare 4-GB-Adressraum in zwei Teile unterteilt: Benutzermodus oder Anwendungsadressraum und Adressraum im Kernelmodus.

Der Adressraum des Benutzermodus ist pro Prozess. Jeder Prozess weist eine andere Zuordnung zwischen Seiten im Adressraum des Benutzermodus und physischem oder virtuellem Speicher auf.

Der Adressraum im Kernelmodus ist derselbe, unabhängig davon, welcher Prozess gerade ausgeführt wird. Andernfalls müsste der Adressraum bei jedem Übergang in den Kernel-Modus neu zugeordnet werden, was sehr ineffizient wäre. (Der Artikel sagt das, aber nur sehr kurz: "Das Betriebssystem macht seinen virtuellen Speicher im Adressraum jedes Prozesses sichtbar.")

Standardmäßig teilt 32-Bit-Windows dies gleichmäßig auf, 2 GB für Benutzer Platz und 2 GB für Kernel-Speicherplatz, aber es kann so konfiguriert werden, dass es stattdessen 3 GB/1 GB aufteilt.

Auf x64-Windows läuft der Kernel im 64-Bit-Modus, so dass er auf den vollen Adressraum zugreifen kann, der von der CPU erlaubt wird, der aktuell 48 Bit oder 256 TB beträgt. Die ersten x64-Windows-Versionen verwendeten nur 16 TB Adressraum, gleichmäßig aufgeteilt: 8 TB für den Anwendungsadressraum (für 64-Bit-Anwendungen) und 8 TB für den Kernel. In Windows 8.1 wurde dies erhöht, um die gesamten von der CPU erlaubten 256 TB zu verwenden, wiederum gleichmäßig aufgeteilt: 128 TB für 64-Bit-Anwendungen, 128 TB für den Kernel.

32-Bit-Anwendungen werden in der WOW64-Emulationsumgebung ausgeführt, wobei die CPU im Legacy-Modus ausgeführt wird. Der Kernel wird jedoch nie im Legacy-Modus ausgeführt. Wenn ein Kernel-Übergang erforderlich ist, muss die CPU vom Legacy-Modus in den Long-Modus geschaltet werden, was auch bedeutet, dass sie vom 32-Bit-Adressraum zum 64-Bit-Adressraum wechselt. x64-CPUs sind so konzipiert, dass dieser Übergang effizient ist.

Als Ergebnis, keine der 32-Bit-Adressraum für den Kernel reserviert werden muss.

Um Abwärtskompatibilität zu gewährleisten, ist ein 32-Bit-Prozess, dessen ausführbare Datei nicht als große Adresse gekennzeichnet ist, weiterhin auf 2 GB Adressraum beschränkt. Wenn die ausführbare Datei große Adresse bewusst ist, erhält der Prozess alle 4GB.

sollten Sie beachten, dass dies wirklich Adressraum, nicht Speicher oder sogar virtuelle Speicher ist. Eine 32-Bit-Anwendung kann Dateizuordnungen und andere Methoden verwenden, um mehr als 4 GB Arbeitsspeicher zu verwenden.

Sie sollten auch beachten, dass die Tatsache, dass der Prozess Zugang zu 2 GB/3GB/4 GB Adressraum bedeutet nicht, dass die Anwendung all den Platz nutzen können. Windows reserviert in jedem Prozess einen Adressraum für den Benutzermodus für sich.

Adressraum und andere Grenzwerte sind hier dokumentiert: Memory Limits for Windows and Windows Server Releases.