☰

Aufteilung auf 32-Bit-Architekturen

tag-icon • tag-icon linux linux-kernel
Aufteilung auf 32-Bit-Architekturen

Ich bin gerade dabei, eine Anwendungssoftware in eine benutzerdefinierte Embedded-Linux-Distribution eines Chipsatz-Anbieters zu integrieren. Dies ist ein ARM-basiertes Produkt, an dem ich arbeite. Mir ist aufgefallen, dass der Kernel in 64 Bit erstellt wird, der restliche Benutzerbereich jedoch in 32 Bit.

Gibt es Leistungsvorteile, wenn man den Kernel als 64-Bit erstellt, obwohl der Benutzerbereich 32-Bit ist? Der SOC basiert auf ARM Cortex-A53.

Jemand hat vorgeschlagen, dass ein 32-Bit-Benutzerspeicherplatz zu einem geringeren RAM-Bedarf für den Benutzerspeicherplatz führt. Dasselbe sollte für den Kernel gelten, aber der Kernel ist 64 Bit. Ich vermute, es gibt eine Leistungssteigerung?

einige Besonderheiten zur Hardware:

  • ARM-Cortex A53
  • 1 GB RAM

PS: Aufgrund von Geheimhaltungsbestimmungen kann ich den Namen des Anbieters nicht bekannt geben.

Antwort1

Der virtuelle Adressraum von Linux-Prozessen ist in zwei Bereiche unterteilt:

  • Kernelspeicher
  • Benutzerbereich.

Aufteilung auf 32-Bit-Architekturen

Auf einer 32-Bit-Architektur, z. B. arm oder i386, beträgt die traditionelle Aufteilung 3:1, wie unten gezeigt:

    +--------+ 0xffffffff
    | Kernel |
    +--------+ 0xc0000000
    |        |
    | User   |
    |        |
    +--------+ 0x00000000
  • Kernelspeicher – 1 GiB
  • Benutzerspeicherplatz – 3 GiB

Somit kann der Kernel höchstens 1 GiB physischen Speichers gleichzeitig zuordnen, es gibt jedoch eine weitere Aufteilung, da wir virtuellen Adressraum für temporäre Zuordnungen benötigen, um auf den Rest des physischen Speichers zugreifen zu können. Die Aufteilung ist wie folgt:

  • Die unteren 896 MiB (0xc0000000 bis 0xf7ffffff) werden direkt dem physischen Adressraum des Kernels zugeordnet.
  • Die verbleibenden 128 MiB (0xf8000000 bis 0xffffffff) werden vom Kernel bei Bedarf zum Zuordnen zum höheren Speicher verwendet.

Die Anordnung ist wie folgt:

                                                 physical memory 2 GiB 
                                          +------> +------------+
                                          |        |  1152 MiB  |  
                                          |        |            |  
    +------------------+ 0xffffffff  -----+        |  HIGH MEM  |  
    | On Demand 128MiB |                           |            |  
    +------------------+ 0xf8000000  ------------> +------------+  
    |                  |             ------+  
    |  Direct mapped   |                   +-----> +------------+   
    |    896 MiB       |             --+           |   896 MiB  |        
    +------------------+ 0xc0000000    +---------> +------------+

Somit bietet der Linux-Kernel über die Highmem-Schnittstelle indirekten Zugriff auf diesen physischen Speicher im Bereich von 2/4/6/8 GiB. Allerdings ist damit die Erstellung temporärer Zuordnungen verbunden, die recht hoch sein können. Der Arch muss die Seitentabellen des Kernels, den Daten-TLB und/oder die Register der MMU bearbeiten.

Auf 64-Bit-Architekturen

Die 3G/1G-Aufteilung ist nicht anwendbar. Aufgrund des riesigen Adressraums kann ein Aufteilungsschema zwischen Benutzer- und Kernelspeicher gewählt werden, das es ermöglicht, den gesamten physischen Speicher in den Kernel-Adressraum abzubilden. Dadurch werden alle Overheads für temporäre Zuordnungen gespart, die bei einer 32-Bit-Architektur anfallen.

Die Unterstützung für hohen Speicher ist optional, wenn der Linux-Kernel auf 64-Bit-Architekturen läuft, und ist sogar deaktiviert, wenn Linux auf 64-Bit-Architekturen läuft.

Referenz:Umgang mit großem Arbeitsspeicher unter Linux.

verwandte Informationen