Schlechte Speicherkapazität im Benutzerbereich für MMAP-physischen Speicher unter Linux

8

Von 192 GB RAM auf meinem Computer installiert, habe ich 188 GB RAM über 4 GB (bei Hardware-Adresse 0x100000000) durch den Linux-Kernel beim Booten reserviert (mem = 4G memmap = 188G $ 4G). Ein Datenerfassungskernmodul akkumuliert Daten in diesem großen Bereich, der unter Verwendung von DMA als ein Ringpuffer verwendet wird. Eine Benutzerraumanwendung kopiert diesen Ringpuffer in den Benutzerbereich und kopiert dann Blöcke aus dem Ringpuffer an der aktuellen Position zur Verarbeitung, sobald sie fertig sind.

Das Kopieren dieser 16MB-Blöcke aus dem MMAP-Bereich mit memcpy funktioniert nicht wie erwartet. Es scheint, dass die Leistung von der Größe des Arbeitsspeichers abhängt, der zum Zeitpunkt des Starts reserviert ist (und später in den Benutzerbereich kopiert wurde). Ссылка enthält den Quellcode für ein Kernelmodul, das die mmap-Dateioperation implementiert:

%Vor%

und eine Testanwendung, die im Wesentlichen funktioniert (wenn die Prüfungen entfernt wurden):

%Vor%

Ich habe Memcpy-Tests eines 16MB Datenblocks für die verschiedenen Größen von reserviertem RAM (resmem_length) unter Ubuntu 10.04.4, Linux 2.6.32, auf einem SuperMicro 1026GT-TF-FM109 durchgeführt:

%Vor%

Meine Beobachtungen sind:

  1. Vom ersten bis zum zweiten Durchlauf scheint memcpy von mmap'ed zu malloc zu profitieren, dass der Inhalt möglicherweise bereits irgendwo zwischengespeichert wird.

  2. Es gibt eine erhebliche Leistungseinbuße von & gt; 64 GB, was sowohl bei Verwendung eines memcpy bemerkt werden kann.

Ich würde gerne verstehen, warum das so ist. Vielleicht dachte jemand in der Linux-Kernel-Entwickler-Gruppe: 64GB sollten für jeden ausreichen (läutet das Klingeln?)

Mit freundlichen Grüßen, Peter

    
PeterW 19.04.2012, 21:24
quelle

2 Antworten

2
___ qstnhdr ___ Schlechte Speicherkapazität im Benutzerbereich für MMAP-physischen Speicher unter Linux ___ answer10237835 ___

Ihre CPU hat wahrscheinlich nicht genug Cache, um effizient damit umgehen zu können. Verwenden Sie entweder niedrigeren Speicher oder eine CPU mit einem größeren Cache.

    
___ tag123memory ___ Verwenden Sie dieses Tag für die Speicherverwaltung oder Probleme beim Programmieren. Bei Fragen zu Speicherhardwareproblemen oder Fehlern in allgemeiner Software rufen Sie https://superuser.com oder https://serverfault.com auf, wenn dies mit Hardware oder Software auf Unternehmensebene zu tun hat. ___ tag123mmap ___ mmap ist ein POSIX-kompatibler Unix-Systemaufruf, der Dateien oder Geräte in den Speicher ablegt. ___ tag123linux ___ LINUX FRAGEN MÜSSEN PROGRAMMIEREN VERWANDT SEIN. Verwenden Sie dieses Tag nur, wenn sich Ihre Frage auf das Programmieren mit Linux-APIs oder das Linux-spezifische Verhalten bezieht, nicht nur, weil Sie Ihren Code unter Linux ausführen. Wenn Sie Linux-Unterstützung benötigen, können Sie https://unix.stackexchange.com oder https://askubuntu.com ausprobieren ___ antwort10300382 ___

Aufgrund der Rückmeldung von SuperMicro ist die Leistungseinbuße auf NUMA, ungleichmäßigen Speicherzugriff, zurückzuführen. Der SuperMicro 1026GT-TF-FM109 verwendet das X8DTG-DF-Motherboard mit einem Intel 5520 Tylersburg-Chipsatz, der mit zwei Intel Xeon E5620-CPUs verbunden ist, die jeweils mit 96 GB RAM ausgestattet sind.

Wenn ich meine Anwendung auf CPU0 sperre, kann ich unterschiedliche Speichergeschwindigkeiten beobachten, je nachdem, welcher Speicherbereich reserviert und folglich gemappt wurde. Wenn der reservierte Speicherbereich außerhalb der CPU liegt, hat mmap Mühe, seine Arbeit zu erledigen, und jedes nachfolgende Memcpy zu und von dem "entfernten" Bereich verbraucht mehr Zeit (Datenblockgröße = 16 MB):

%Vor%

Es macht fast Sinn. Nur der dritte Fall, 64G $ 128, was die obersten 64GB bedeutet, liefert ebenfalls gute Ergebnisse. Das widerspricht irgendwie der Theorie.

Grüße, Peter

    
___ qstntxt ___

Von 192 GB RAM auf meinem Computer installiert, habe ich 188 GB RAM über 4 GB (bei Hardware-Adresse 0x100000000) durch den Linux-Kernel beim Booten reserviert (mem = 4G memmap = 188G $ 4G). Ein Datenerfassungskernmodul akkumuliert Daten in diesem großen Bereich, der unter Verwendung von DMA als ein Ringpuffer verwendet wird. Eine Benutzerraumanwendung kopiert diesen Ringpuffer in den Benutzerbereich und kopiert dann Blöcke aus dem Ringpuffer an der aktuellen Position zur Verarbeitung, sobald sie fertig sind.

Das Kopieren dieser 16MB-Blöcke aus dem MMAP-Bereich mit memcpy funktioniert nicht wie erwartet. Es scheint, dass die Leistung von der Größe des Arbeitsspeichers abhängt, der zum Zeitpunkt des Starts reserviert ist (und später in den Benutzerbereich kopiert wurde). Ссылка enthält den Quellcode für ein Kernelmodul, das die mmap-Dateioperation implementiert:

%Vor%

und eine Testanwendung, die im Wesentlichen funktioniert (wenn die Prüfungen entfernt wurden):

%Vor%

Ich habe Memcpy-Tests eines 16MB Datenblocks für die verschiedenen Größen von reserviertem RAM (resmem_length) unter Ubuntu 10.04.4, Linux 2.6.32, auf einem SuperMicro 1026GT-TF-FM109 durchgeführt:

%Vor%

Meine Beobachtungen sind:

  1. Vom ersten bis zum zweiten Durchlauf scheint memcpy von mmap'ed zu malloc zu profitieren, dass der Inhalt möglicherweise bereits irgendwo zwischengespeichert wird.

  2. Es gibt eine erhebliche Leistungseinbuße von & gt; 64 GB, was sowohl bei Verwendung eines memcpy bemerkt werden kann.

Ich würde gerne verstehen, warum das so ist. Vielleicht dachte jemand in der Linux-Kernel-Entwickler-Gruppe: 64GB sollten für jeden ausreichen (läutet das Klingeln?)

Mit freundlichen Grüßen, Peter

    
___
PeterW 24.04.2012 14:48
quelle
1

Ihre CPU hat wahrscheinlich nicht genug Cache, um effizient damit umgehen zu können. Verwenden Sie entweder niedrigeren Speicher oder eine CPU mit einem größeren Cache.

    
Ignacio Vazquez-Abrams 19.04.2012 22:35
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Wie testet man Google Plus API (Google Plus Testkonto)?