In meinem Programm habe ich mehrere Threads, die mit dem Prozess gestartet werden und bis zum Ende des Programms bestehen bleiben. Sie werden während der Lebensdauer der App unterschiedlichen Belastungen ausgesetzt sein und zeitweise alle zu 100 % laufen.
Standardmäßig ändert der Linux-Thread-Scheduler die Affinität für diese Threads auf einem Multi-Core-System meiner Meinung nach ziemlich leichtfertig. Wenn ich mir die springenden Diagramme in meinem grafischen Prozessmonitor (dem in Gnome) ansehe, kann ich nicht anders, als zu denken, dass dies eine Art Overhead darstellt.
BEARBEITEN:Zur Verdeutlichung: Selbst bei sehr stabilen Lasten werden die Threads auf unterschiedlichen Kernen geplant, und obwohl es im bereitgestellten Bild nicht sichtbar ist, ist es manchmal sehr deutlich, dass der für jeden Thread ausgewählte Kern häufig „ausgetauscht“ wird.
Wird sich dieser ständige Wechsel der Affinität nicht negativ auf die Leistung auswirken?
Warum wird es dann so umgesetzt? Welche Vorteile hat die Änderung der Affinität?
Meine Vermutungen sind:
- Wear Levelling - Legen Sie nicht die ganze Arbeit auf einen Kern
- Unbeabsichtigt – Einige intelligente Algorithmen versuchen, die Nutzung je nach Belastung zu optimieren, und es kommt vor, dass der Mehraufwand nicht signifikant genug ist, um die Beibehaltung der Affinität gegenüber einer Änderung zu rechtfertigen.
Antwort1
Wenn Sie alle Threads auf einem Core ausführen möchten, kaufen Sie günstigere Hardware mit einem einzelnen Core.
Der Scheduler versucht, alle Kerne optimal zu nutzen. Dies bedeutet, dass Threads an den Kern gesendet werden, der etwas freie Zeit hat. Das Verschieben eines Threads von einem Kern zu einem anderen verursacht nur geringe Kosten, daher versucht der Scheduler, dies zu vermeiden. Sie werden dies jedoch normalerweise nicht sehr bemerken, da der Nutzen, einen Kern nicht ungenutzt zu lassen, weitaus größer ist als die Kosten für die Migration eines Threads. Dies gilt insbesondere dann, wenn die Threads mehr Speicher verwenden, als Sie über lokalen Kerncache verfügen: Wenn der von einem Thread verwendete Speicher nicht im lokalen Kerncache vorhanden ist, geht durch die Migration auf einen anderen Kern nur sehr wenig verloren.
Das Nachdenken über einen Scheduler auf Industrieniveau wie den von Linux verschlechtert normalerweise die Leistung.
Die von Ihnen angezeigten Diagramme zeigen, dass die Belastung der verschiedenen Kerne nicht vollständig und leicht variabel ist, vermutlich weil Ihr System als Ganzes durch die E/A für die gerade ausgeführten Aufgaben begrenzt ist und nicht durch die CPU-Leistung. Es sagt nichts darüber aus, wie oft Threads von einem Kern zum anderen wechseln.
Antwort2
Der hier bereitgestellte Snapshot hängt auch vom Typ (der Version) des Kernels ab. Ältere Kernel mit Version 2.4 hatten eine schlechte Affinität, was zu vielen Ping-Pong-Bewegungen der Threads führte, die die Leistung des Systems beeinträchtigten. Kernel-Versionen ab 2.5 haben eine relativ bessere Affinität.
Auf einem Multi-Core-basierten System kann das Festlegen der Affinität die Leistung verbessern, indem beim Verschieben eines Threads zwischen den Kernen das Auftreten einer Cache-Invalidierung vermieden wird.
Bei Linux-basierten Multi-Core-Systemen kann das Affinitätsverhalten des Schedulers (natürliche Affinität) je nach Anwendungs-/Anforderungstyp durch Verwendung von sched_setaffinity/taskset für den Prozess und pthread_setaffinity_np für den Thread außer Kraft gesetzt werden.
Kernelhaischeint eine bessere visuelle Darstellung des Multi-Core-Systems und der Affinität zu bieten.
Beachten Sie auch, dasshtopbietet visuelle Unterstützung zum Festlegen der Affinität (um den Scheduler zu überschreiben).