Linux ermitteln des Hyper-threaded-Kern-IDs

Question

Ich habe diesen Morgen damit verbracht, herauszufinden, wie man feststellen kann, welche Prozessor-ID der hyper-threaded Kern ist, aber ohne Erfolg.

Ich möchte diese Informationen herausfinden und set_affinity() verwenden, um einen Prozess an den hyper-threaded Thread oder den nicht-hyper-threaded Thread zu binden, um dessen Leistung zu profilem.

Answer 1

Ich habe den einfachen Trick entdeckt, um das zu tun, was ich brauche.

cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

Wenn die erste Zahl der CPU-Nummer entspricht (0 in diesem Beispiel), handelt es sich um einen echten Kern. Andernfalls handelt es sich um einen Hyperthreading-Kern.

Beispiel für einen echten Kern:

# cat /sys/devices/system/cpu/cpu1/topology/thread_siblings_list
1,13

Beispiel für einen Hyperthreading-Kern:

# cat /sys/devices/system/cpu/cpu13/topology/thread_siblings_list
1,13

Die Ausgabe des zweiten Beispiels ist genau die gleiche wie die des ersten. Wir überprüfen jedoch cpu13 und die erste Zahl ist 1, daher handelt es sich um einen Hyperthreading-Kern.

Answer 2

Ich bin überrascht, dass noch niemand lscpu erwähnt hat. Hier ist ein Beispiel für ein Einzel-Sockel-System mit vier physischen Kernen und aktivierter Hyper-Threading:

$ lscpu -p
# Das folgende ist das analysierbare Format, das an andere
# Programme weitergegeben werden kann. Jedes unterschiedliche Element in jeder Spalte hat eine eindeutige ID
# die bei null beginnt.
# CPU,Core,Socket,Node,,L1d,L1i,L2,L3
0,0,0,0,,0,0,0,0
1,1,0,0,,1,1,1,0
2,2,0,0,,2,2,2,0
3,3,0,0,,3,3,3,0
4,0,0,0,,0,0,0,0
5,1,0,0,,1,1,1,0
6,2,0,0,,2,2,2,0
7,3,0,0,,3,3,3,0

Die Ausgabe erklärt, wie man die Tabelle der IDs interpretiert; logische CPU-IDs mit derselben Core-ID sind Geschwister.

Answer 3

HT ist symmetrisch (in Bezug auf grundlegende Ressourcen, der Systemmodus kann jedoch asymmetrisch sein).

Also, wenn HT eingeschaltet ist, werden große Ressourcen des physikalischen Kerns zwischen zwei Threads geteilt. Es wird zusätzliche Hardware eingeschaltet, um den Status beider Threads zu speichern. Beide Threads haben symmetrischen Zugriff auf den physischen Kern.

Es gibt einen Unterschied zwischen einem deaktivierten HT-Kern und einem aktivierten HT-Kern; aber keinen Unterschied zwischen der ersten Hälfte des aktivierten HT-Kerns und der zweiten Hälfte des aktivierten HT-Kerns.

Zu einem bestimmten Zeitpunkt kann ein HT-Thread mehr Ressourcen als der andere nutzen, aber diese Ressourcenverteilung ist dynamisch. Die CPU wird die Threads ausbalancieren, wenn sie können und wenn sie wollen, falls beide Threads dieselbe Ressource nutzen möchten. Sie können in einem Thread nur ein rep nop oder pause durchführen, um der CPU mehr Ressourcen für den anderen Thread zu geben.

Ich möchte diese Informationen herausfinden und set_affinity() verwenden, um einen Prozess an einen hyper-threaded Thread oder einen nicht-hyper-threaded Thread zu binden, um seine Leistung zu analysieren.

Okay, Sie können tatsächlich die Leistung messen, ohne die tatsächlichen Fakten zu kennen. Führen Sie einfach ein Profiling durch, wenn der einzige Thread im System an CPU0 gebunden ist; und wiederholen Sie es, wenn er an CPU1 gebunden ist. Ich denke, die Ergebnisse werden fast gleich sein (das Betriebssystem kann eine Störung verursachen, wenn es einige Unterbrechungen an CPU0 bindet; versuchen Sie also die Anzahl der Unterbrechungen bei den Tests zu reduzieren und verwenden Sie CPU2 und CPU3, wenn Sie diese haben).

PS

Agner (er ist der Guru im x86) empfiehlt, die geradzahligen Kerne zu verwenden, wenn Sie HT nicht nutzen möchten, es jedoch im BIOS aktiviert ist:

Wenn Hyperthreading erkannt wird, sperren Sie den Prozess so, dass nur die logischen Prozessoren mit geradzahligen Nummern verwendet werden. Dadurch wird einer der beiden Threads in jedem Prozessorkern leer, sodass es keinen Wettbewerb um Ressourcen gibt.

PPS Über den neuen Wiedergeburt HT (nicht die des P4, sondern Nehalem und Sandy) - basierend auf Agners Forschung zur Mikroarchitektur

Die neuen Engpässe, die in der Sandy Bridge Beachtung finden müssen, sind folgende: ... 5. Teilen von Ressourcen zwischen Threads. Viele kritische Ressourcen werden zwischen den beiden Threads eines Kerns geteilt, wenn Hyperthreading aktiviert ist. Es kann ratsam sein, Hyperthreading zu deaktivieren, wenn mehrere Threads von denselben Ausführungsressourcen abhängen.

...

Ein Mittelweg wurde bei NetBurst und erneut bei Nehalem und Sandy Bridge mit der sogenannten Hyperthreading-Technologie eingeführt. Der Hyperthreading-Prozessor verfügt über zwei logische Prozessoren, die denselben Ausführungskern teilen. Der Vorteil davon ist begrenzt, wenn die beiden Threads um dieselben Ressourcen konkurrieren, aber Hyperthreading kann durchaus vorteilhaft sein, wenn die Leistung durch andere Faktoren begrenzt ist, wie z.B. Speicherzugriff.

...

Sowohl Intel als auch AMD entwickeln Hybridlösungen, bei denen einige oder alle Ausführungseinheiten zwischen zwei Prozessorkernen geteilt werden (Hyperthreading in Intels Terminologie).

PPPS: Das Intel-Optimierungsbuch listet Ressourcenaufteilung in der Hyperthreading der zweiten Generation auf: (Seite 93, diese Liste gilt für Nehalem, aber es gibt keine Änderungen in dieser Liste im Abschnitt Sandy)

Tiefere Pufferung und verbesserte Ressourcenaufteilungs- / partitionierungspolitik:

• — Reproduzierbare Ressourcen für HT-Betrieb: Registerstatus, umbenannter Rücksprungpuffer, großer ITLB für Seiten //Kommentar von mir: Es gibt 2 Sätze dieser Hardware
• — Partitionierte Ressourcen für HT-Betrieb: Lade-Puffer, Speicher-Puffer, Umordnung Puffer, kleiner ITLB für Seiten sind statisch zwischen den beiden logischen Prozessoren aufgeteilt. // Kommentar von mir: Es gibt einen Satz dieser Hardware; er ist statisch zwischen zwei HT-Virtualcores in zwei Hälften aufgeteilt
• — Konkurrenzgeteilte Ressourcen während HT-Betrieb: Die Reservierungsstation, Cache-Hierarchie, Füllpuffer, sowohl DTLB0 als auch STLB. // Kommentar: Ein Satz, aber nicht zur Hälfte geteilt. Die CPU teilt die Ressourcen dynamisch neu auf.
• — Alternierend während HT-Betrieb: Der Front-End-Betrieb wechselt normalerweise zwischen den beiden logischen Prozessoren, um Fairness zu gewährleisten. // Kommentar: Es gibt nur ein Frontend (Instruktionsdecoder), sodass Threads in folgender Reihenfolge dekodiert werden: 1, 2, 1, 2.
• — HT-unbewusste Ressourcen: Ausführungseinheiten. // Kommentar: Es gibt tatsächliche Hardwaregeräte, die Berechnungen, Speicherzugriffe durchführen werden. Es gibt nur einen Satz. Wenn einer der Threads viele Ausführungseinheiten nutzen kann und nur selten auf den Speicher warten muss, wird er alle Ausführungseinheiten nutzen, und die Leistung des zweiten Threads wird gering sein (aber HT wird manchmal zum zweiten Thread wechseln. Wie oft??? ). Wenn beide Threads nicht stark optimiert sind und/oder auf den Speicher warten müssen, werden die Ausführungseinheiten zwischen den beiden Threads aufgeteilt.

Auf Seite 112 gibt es auch Bilder (Abbildung 2-13), die zeigen, dass beide logischen Kerne symmetrisch sind.

Das Leistungspotenzial der HT-Technologie beruht auf:

• • Der Tatsache, dass Betriebssysteme und Benutzerprogramme Prozesse oder Threads planen können, um gleichzeitig auf den logischen Prozessoren in jedem physischen Prozessor ausgeführt zu werden
• • Die Möglichkeit, die On-Chip-Ausführungsressourcen auf einem höheren Niveau als bei nur einem Thread, der die Ausführungsressourcen verbraucht, zu nutzen; eine höhere Nutzung der Ressourcen kann zu einem höheren Systemdurchsatz führen

Obwohl Befehle aus zwei Programmen oder Threads gleichzeitig und nicht unbedingt in der Programmareihenfolge im Ausführungskern und im Speicherhierarchie ausgeführt werden, besitzen der Front-End und der Back-End mehrere Auswahlpunkte zum Auswählen zwischen Befehlen der beiden logischen Prozessoren. Alle Auswahlpunkte wechseln sich zwischen den beiden logischen Prozessoren ab, es sei denn, ein logischer Prozessor kann eine Pipelinestufe nicht nutzen. In diesem Fall hat der andere logische Prozessor die volle Nutzung jedes Zyklus der Pipelinestufe. Gründe, warum ein logischer Prozessor eine Pipelinestufe nicht nutzen kann, umfassen Cache-Misses, Zweigfehleinschätzungen und Befehlsabhängigkeiten.

Answer 4

Es gibt einen universellen (Linux/Windows) und portablen HW-Topologie-Detektor (Kerne, HT, Caches, South Bridges und Disk/Netzwerk-Verbindungen) - hwloc vom OpenMPI-Projekt. Du kannst es verwenden, da Linux möglicherweise unterschiedliche HT-Kernnummerierungsregeln verwendet und wir nicht wissen können, ob es eine geradzahlige/ungeradzahlige oder eine y und y+8 Nummerierungsregel sein wird.

Homepage von hwloc: http://www.open-mpi.org/projects/hwloc/

Download-Seite: http://www.open-mpi.org/software/hwloc/v1.10/

Beschreibung:

Das Portable Hardware Locality (hwloc) Softwarepaket bietet eine portable Abstraktion (über Betriebssysteme, Versionen, Architekturen, ...) der hierarchischen Topologie moderner Architekturen, einschließlich NUMA-Speicherknoten, Sockets, gemeinsamer Caches, Kerne und simultanem Multithreading. Es sammelt auch verschiedene Systemattribute wie Cache- und Speicherinformationen sowie die Lokalität von I/O-Geräten wie Netzwerkschnittstellen, InfiniBand HCAs oder GPUs. Es zielt in erster Linie darauf ab, Anwendungen bei der Informationssammlung über moderne Computerhardware zu helfen, um sie entsprechend und effizient nutzen zu können.

Es hat den Befehl lstopo um die hw-Topologie grafisch darzustellen wie

 ubuntu$ sudo apt-get hwloc
 ubuntu$ lstopo

oder in Textform:

 ubuntu$ sudo apt-get hwloc-nox
 ubuntu$ lstopo --of console

Wir können physische Kerne als Kern L#x sehen, wobei jeder zwei logische Kerne PU L#y und PU L#y+8 hat.

Rechner (16GB)
  Steckplatz L#0 + L3 L#0 (4096KB)
    L2 L#0 (1024KB) + L1 L#0 (16KB) + Kern L#0
      PU L#0 (P#0)
      PU L#1 (P#8)
    L2 L#1 (1024KB) + L1 L#1 (16KB) + Kern L#1
      PU L#2 (P#4)
      PU L#3 (P#12)
  Steckplatz L#1 + L3 L#1 (4096KB)
    L2 L#2 (1024KB) + L1 L#2 (16KB) + Kern L#2
      PU L#4 (P#1)
      PU L#5 (P#9)
    L2 L#3 (1024KB) + L1 L#3 (16KB) + Kern L#3
      PU L#6 (P#5)
      PU L#7 (P#13)
  Steckplatz L#2 + L3 L#2 (4096KB)
    L2 L#4 (1024KB) + L1 L#4 (16KB) + Kern L#4
      PU L#8 (P#2)
      PU L#9 (P#10)
    L2 L#5 (1024KB) + L1 L#5 (16KB) + Kern L#5
      PU L#10 (P#6)
      PU L#11 (P#14)
  Steckplatz L#3 + L3 L#3 (4096KB)
    L2 L#6 (1024KB) + L1 L#6 (16KB) + Kern L#6
      PU L#12 (P#3)
      PU L#13 (P#11)
    L2 L#7 (1024KB) + L1 L#7 (16KB) + Kern L#7
      PU L#14 (P#7)
      PU L#15 (P#15)

Answer 5

Einfacher Weg, um die Hyperthreading-Geschwister der CPU-Kerne in Bash zu erhalten:

cat $(find /sys/devices/system/cpu -regex ".*cpu[0-9]+/topology/thread_siblings_list") | sort -n | uniq

Es gibt auch lscpu -e, das relevante Kern- und CPU-Informationen liefert:

CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ    MINMHZ
0   0    0      0    0:0:0:0       yes    4100.0000 400.0000
1   0    0      1    1:1:1:0       yes    4100.0000 400.0000
2   0    0      2    2:2:2:0       yes    4100.0000 400.0000
3   0    0      3    3:3:3:0       yes    4100.0000 400.0000
4   0    0      0    0:0:0:0       yes    4100.0000 400.0000
5   0    0      1    1:1:1:0       yes    4100.0000 400.0000
6   0    0      2    2:2:2:0       yes    4100.0000 400.0000
7   0    0      3    3:3:3:0       yes    4100.0000 400.0000