X86- und x64-Prozessoren ermöglichen Seiten mit 1 GB, wenn das PDPE-Flag auf der CPU gesetzt ist. In welcher Anwendung wäre dies praktisch oder erforderlich und aus welchem Grund?Welche Anwendungen benötigen 1 GB Seiten?
Stellen Sie sich eine Anwendung vor, die große Mengen an Speicher verwendet - Molecular Modeling. Wettervorhersage - vor allem, wenn es keine Benutzerinteraktion hat.
große Seiten:
(1) verringern die Menge des Seitentabellenüberkopfspeicher (2) erhöht die Menge an Speicher, die in dem Cache-MMU gespeichert werden können. (Die gleiche Anzahl von Cache-Einträgen verweist auf mehr Speicher).
Huugepage würde in Fällen helfen, in denen Sie einen großen Speicherbedarf haben und das Speicherzugriffsmuster große Entfernungen überbrückt (über 4K-Seiten).
Es reduziert nicht nur TLB-Fehler, sondern spart OS mm System Seitentabellen Größe.
Ein sehr gutes Beispiel ist die Paketverarbeitung. In Netzwerkanwendungen mit hohem Durchsatz (1 Gbps oder mehr) werden Pakete normalerweise in einem Paketpufferpool gespeichert (d. H. Pooling-Technik). Zum Beispiel ist jeder Paketpuffer 2 KB groß und der Pool enthält 512 Puffer. Das Zugriffsmuster dieses Paketpufferpools ist möglicherweise nicht sequenziell (der Puffer ist bei 1,2,3,4,5 ... indiziert), sondern zufällig über die Zeit (1,104,407,45,905 ...). Da normale Seitengröße 4K ist, wird normaler TLB hier nicht helfen, da jeder Paketzugriff einen TLB-Fehltreffer verursachen würde und es viele verschiedene Puffer auf verschiedenen Seiten gibt.
Im Gegensatz dazu, wenn Sie den Pool in eine 1GB rugpage setzen, dann teilen alle Paketpuffer den gleichen rgagepageTLB Eintrag und vermeiden somit Fehler.
Dies wird in DPDK (Data Plane Development Kit) verwendet, wo die Paket Rate ist sehr hoch, dass Zyklen vergeudet TLB Miss ist nicht vernachlässigbar.
hugepage Unterstützung für die große Speicherpoolzuweisung verwendete erforderlich ist für Paketpuffer (die hugetlbfs Option muss im laufenden Kernel aktiviert werden, wie im vorherigen Abschnitt angegeben). Durch die Verwendung von hugepage Zuordnungen wird die Leistung erhöht, da weniger Seiten benötigt werden, und weniger Translation Lookaside Buffers (TLBs, hohe Übersetzungs-Caches), die die Zeit für die Übersetzung einer virtuellen Seitenadresse in eine physische Seitenadresse reduzieren . Ohne große Seiten würden hohe TLB-Fehltreffer-Raten mit der Standard-4k-Seitengröße, Verlangsamungsleistung auftreten.
http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#bios-setting-prerequisite-on-x86
Ein weiteres Beispiel von Oracle:
... fast 6,8 GB Speicher für Seitentabellen verwendet, wenn hugepages nicht konfiguriert waren ...
... nachdem riesige Seiten von der Oracle-Datenbank zugewiesen und verwendet wurden.Die Overhead-Seitentabelle wurde reduziert auf etwas weniger als 23 MB
http://www.databasejournal.com/features/oracle/understanding-hugepages-in-oracle-database.html
Weiterführende Links:
https://en.wikipedia.org/wiki/Object_pool_pattern
--Edit--
Allerdings sollte hugepage verwendet werden vorsichtig. Oben erwähnte ich, dass der Speicherpool von 1GB rugpage profitieren würde. Wenn Sie jedoch ein Zugriffsmuster auch über die Seitengrenze von 1 GB hinaus haben, hilft das möglicherweise nicht. Es gibt eine ausgezeichnete Blog dazu:.
ich LabView installiert haben auf meinem Dell ws mit 8 Kernen und 16 GB DDRM, driving 4 24" Monitore
Wenn ich einen Videoprozessor oder Setzer der meisten jeder erstellen Typ, mit einem 1024px x 1024px "Zeichnung" Display reserviert LabView 1,5GB, bevor ich überhaupt begann zu composite.Es wurde aus C und C++.
Ich speicher oft Bilddetails in 3D-Arrays von 256 x 256 x 256 U32 Ganzzahlen Das sind 64 MB pro Schicht gepuffertes Video. Wenn ich 128 Ebenen merken muss, sind das genau 8 GB.
L abView ist eine Programmiersprache, die wie ein CAD-Programm strukturiert ist. Wenn ich 8 GB für eine Reihe von Video (HDTV) -Puffern brauche, dann ist es das, was es mir geben wird, mit ein paar Sekunden warten, bis malloc seine Arbeit macht.
Wenn ich ein 8GB 3D-Array für eine Datenbank erstellt, wäre es nicht anders, auch wenn ich es in MySQL (nicht als Array) getan hätte. Für mich ist es nicht ungewöhnlich, viele Gigabyte RAM zu haben, um damit zu spielen.
Es ist schwer, sich eine Anwendung vorzustellen, wo es * erforderlich * sein könnte. * Vorteilhaft * ist wahrscheinlich ein besserer Begriff - und gilt, wenn 1) eine 1-GB-Seite vollständig oder nahezu vollständig belegt ist, weniger Speicherplatz verschwendet wird und 2) in Seitentabellen und TLB-Einträgen starke Abwanderung stattfindet - größere Seiten bedeuten weniger Einträge pro Person GB Speicher und reduziert somit den Druck auf die virtuelle Speicherhardware/-software. – twalberg
Es scheint nur eine außergewöhnliche Größe für seltene Situationen. Bei Recherchen kann ich nichts finden, was eine so große Seitengröße erfordert, wenn man bedenkt, dass die Mehrzahl der Seitengrößen 4096 Bytes beträgt (standardmäßig mindestens). – BugHunterUK