24
Die Standard-Speicherseitengröße des Linux-Kernels auf x86-Architektur war 4 KB, ich frage mich, wie wurde das berechnet, und warum?Warum ist die Seitengröße von Linux (x86) 4 KB, wie wird das berechnet?
A
Antwort
27
Die Standardgröße der Seite wird durch die Unterstützung der MMU (Memory Management Unit) der CPU festgelegt. In 32-Bit-Protected-Mode-x86 unterstützt zwei Arten von Seiten:
- normale, 4 KiB
- gigantisch große, 4 MiB
Nicht alle x86-Prozessoren unterstützen große Seiten. Man benötigt eine CPU mit PSE-Funktionen (Page Size Extension). Dies schließt Pre-Pentium-Prozessoren aus. Praktisch alle aktuellen x86-CPUs implementieren es.
4 KiB ist auch in anderen Architekturen weit verbreitet. Man könnte argumentieren, dass diese Größe von der Aufteilung einer 32-Bit virtuellen Adresse in zwei 10-Bit Indizes in Seitenverzeichnisse/Tabellen herrührt und die restlichen 12 Bits die 4 KiB Seitengröße ergeben.
2
Ich habe diese vom Wikipedia-Artikel und ich zitiere:
Seitengröße in der Regel durch Prozessorarchitektur bestimmt wird
Überprüfen Sie den Artikel unten aus:
12
That depends on the processor architecture.
Die Standardseitengröße beträgt 4 KB auf vielen Architekturen. Es kann im Allgemeinen (manchmal sehr, wie 1 GB von AMD64) erhöht werden, indem man zum huge page Modus wechselt. Dadurch kann die Seitentabelle kleiner werden, was zu Leistungsverbesserungen führen kann.
17
Das Design von 4 KB normaler Seitengröße von 32-Bit-Architektur ist eigentlich sehr interessant :)
Und ich mag eine zusätzliche Antwort hinzufügen zu zeigen, warum es sinnvoll ist.
x86 verwendet '2-pass', um virtuelle Speicheradressen in physikalische Speicheradressen zu übersetzen.
Nehmen wir an, dass sowohl das Seitenverzeichnis als auch die Seitentabelle 
Einträge enthalten und die Seitengröße 
Bytes ist. Um eine volle Nutzung der 
Adresse zu machen, haben wir:
Jeder Eintrag in Seitenverzeichnis/Tabelle verbraucht 4 Byte (32-Bit), also:
So y = 12, und die Seitengröße in Bytes ist = 
= 4KB.
Und was ist mit "1-Pass"? Das ist interessant, weil wir logisch eine einzelne Seitentabelle für Adressensuche verwenden können.
Angenommen, das Seitenverzeichnis enthält 
Einträge, die jeweils eine Adresse der entsprechenden Seite zuordnen, und die Seitengröße ist 
Bytes.
Noch einmal, vollen Gebrauch von Adressen zu machen, brauchen wir:
Und:
Wir y 17 = bekommen, und die Seitengröße ist = 
= 128 KB.
Wie auch immer, das funktioniert "logisch". Wenn wir TLB vorstellen, wird solch eine große Speichergröße ein Diaster sein: Speicherseiten werden zu schwer in TLB passen, und das Design wird nicht effizient sein.
Wir auch, dass in ‚2-pass‘ -Version können unterschiedliche Größen haben, Seitenverzeichnis und Seitentabelle argumentieren könnte. Dies bedeutet jedoch, dass wir ein größeres Seitenverzeichnis verwenden, das mehr als eine Speicherseite belegt. Leider muss jedesmal, wenn ein neuer Benutzerprozess erzeugt wird, das Betriebssystem für sein eigenes Seitenverzeichnis aufeinanderfolgende Seiten zuweisen, was nicht elegant ist.
+0
Die normale Terminologie ist "2-Level-Seitentabelle", nicht "2-Pass". z.B. [x86-64 verwendet eine vierstufige Seitentabelle] (https://stackoverflow.com/questions/46509152/why-in-64bit-the-virtual-address-are-4-bits-short-48bit-long-compared (mit 4k normalen Seiten, aber riesige Seiten sind 2M oder 1G statt 4M.) –
+0
Ihr 1-Level-Seitentabellenabschnitt macht eine unnötige Annahme: Die Seitentabelle selbst * hat keine * 1 Seite Größe. Du könntest kleinere Seiten haben (und einen noch gigantischeren flachen Seitentabelle).Was an 1-Level saugt, ist die Größe der Seitentabelle: Ein Prozess mit nur einer kleinen Speichermenge kann einen dünnen Baum mit nur ein paar untergeordneten Seitentabellen haben. TLB ist überhaupt kein Problem; Jeder TLB enthält die vollständige Übersetzung von allen Ebenen der Seitentabelle, so dass größere Seiten weniger Seitenbits bedeuten, was ein kleineres CAM bedeutet. Und weniger TLB-Einträge decken mehr Speicher ab. –
0
Ich füge diese Antwort/Anmerkung hinzu, weil die Berechnung von sleesort sehr interessant ist, muss ich es meiner Web site hinzufügen (mit der Quelle selbstverständlich erwähnen). Eine (mögliche) Antwort auf die Frage, wie Sie die Seitengröße programmatisch berechnen können, finden Sie unter here. Die Art und Weise wie es berechnet wird, ist sehr interessant. Ich tat das gleiche für x86_64 und das Ergebnis war nicht das, was ich erwartet hatte. Allerdings weiter lesen auf memory management x86_64 Ich fand, dass für 64-Bit-Intel, 16 Bits nicht verwendet werden, lassen Sie es 48 Bits für uns zu berechnen. 9 Bits für die Speicherbaumzweige, jeder Zweig weitere 9 Bits, hier in einem anderen 9 für Zweige und schließlich 9 Bits für die Blätter des letzten Zweigs. Also 48 - 36 = 12 Bits für jede Adresse auf der Speicherseite. 2^12 = 4096 wie zuvor von sleesort erwähnt. Ich frage mich nur, wie viele Pass diese Architektur, 3 oder 4 (wenn jemand kann mir das erklären) Berechnung folgende sleepsort suchen:
2^x * 2^x * 2^x * 2^x * 2^y = 2^48
4x + y = 48
this time we have 8 bytes for each address (8 bytes * 8 bits/byte = 64 bits)
2^y/2^3 = 2^x
y - 3 = x
filled in in previous equation:
4(y - 3) + y = 48
4y - 12 + y = 48
5y = 60
y = 12
because 2^y represents the pagesize, the size = 2^12 = 4096 bytes
Lassen Sie mich mit der Frage „was ist mit den großen Seiten in Linux“?
4M große Seiten sind nur für 32-Bit-Modus x86. 64-Bit x86 verwendet 2M- oder 1G-Großseiten, da das 4-Level-Seitentabellenformat 9 Bits pro Ebene verwendet. https://stackoverflow.com/questions/46509152/why-in-64bit-the-virtual-address-are-4-bits-short-48bit-long-compared-with-the. (Die nicht sehr große Seitengröße ist immer noch 4k im langen Modus, so dass der L1DTLB- und der L1D-Cache unter anderen Gründen immer noch grundsätzlich gleich funktionieren können.) –
@PeterCordes, danke für Ihren Kommentar. Ich habe tatsächlich nur den 32-Bit-Modus angesprochen und das ist, was ich normalerweise mit x86 bezeichne. –