Schlagwort: Sysadmin (Seite 1 von 13)

Auf meiner alten Maschine standen zwei Prozessoren. Das klingt erst einmal nach doppelt so gut, und in Wahrheit war es vor allem doppelt so kompliziert. Ich habe damals ziemlich viel Zeit damit verbracht, einem Spiel beizubringen, dass es bitte auf der Hälfte der CPU laufen soll, und zwar auf derjenigen, an der auch die Grafikkarte hängt, weil der Weg zur anderen Hälfte zu lang war. Das Werkzeug dafür heisst NUMA, und wer einmal damit zu tun hatte, vergisst es nicht mehr.

Die neue Maschine hat einen Sockel. Damit ist das Thema erledigt, dachte ich. Ist es nicht ganz, und diese Folge erklärt warum. Es geht um Advanced > Chipset Configuration > North Bridge > Uncore Configuration und um zwei Zeilen aus den ACPI-Einstellungen. Alle Folgen dieser Serie stehen unter BIOS & Firmware.

Was Uncore überhaupt ist

Der Begriff kommt von Intel und meint alles auf dem Prozessorchip, was kein Rechenkern ist. Der gemeinsame L3-Cache. Die Speichercontroller. Die PCIe-Root-Ports. Das Verbindungsnetz, das all das miteinander verbindet. Bei einem modernen Xeon ist der Uncore flächenmässig ein erheblicher Teil des Chips und verbraucht auch einen erheblichen Teil des Stroms.

Der Uncore hat einen eigenen Takt, unabhängig von den Kernen. Er läuft weiter, wenn alle Kerne schlafen, denn irgendjemand muss ja mitbekommen, wenn eine Netzwerkkarte etwas will. Wenn man in Datenblättern liest, dass ein Serverprozessor im Leerlauf noch 40 Watt zieht, obwohl er angeblich nichts tut, ist das zum guten Teil der Uncore.

Die Kopfzeilen sagen mehr als der Rest

Number of CPU                     1
Number of IIO                     1
Current UPI Link Speed            Slow or 1S Configuration
Current UPI Link Frequency        Unknown or 1S configuration

Diese vier Zeilen finde ich fast rührend. UPI ist Ultra Path Interconnect, Intels Verbindung zwischen zwei Prozessoren in einem System. Über sie laufen Speicherzugriffe auf den Speicher des jeweils anderen und die gesamte Cache-Kohärenz, also die Buchhaltung darüber, wer gerade welche Speicherzeile in seinem Cache liegen hat.

Bei mir steckt genau eine CPU im Board. Also gibt es niemanden, mit dem geredet werden müsste, und das Setup sagt das auf seine eigene Art: 1S Configuration, Single Socket. Die Firmware weiss es, das Menü existiert trotzdem, weil dasselbe BIOS auch auf Zwei-Sockel-Boards läuft.

Number of IIO ist die Zahl der Integrated IO Hubs, also der Einheiten, die die PCIe-Lanes bereitstellen. Bei einem Sockel logischerweise eins.

Interessanter sind die Adressbereiche darunter:

Global MMIO Low Base / Limit      90000000 / FBFFFFFF
Global MMIO High Base / Limit     0000200000000000 / 0000204FFFFFFFFF
PCIe Configuration Base / Size    80000000 / 10000000

Das ist die Speicherlandkarte für alles, was nicht RAM ist. Der untere Bereich liegt unterhalb von 4 GB, ist entsprechend eng und wird knapp, sobald mehrere Karten mit grossen Speicherfenstern stecken. Der obere beginnt bei 0x200000000000, also bei 32 Terabyte, und ist der Grund, warum meine Grafikkarte ihre kompletten 16 GB Videospeicher einblenden kann. Dazu mehr in der Folge über Above 4G Decoding und Resizable BAR.

NUMA, obwohl es nichts zu verteilen gibt

Zwei Menüs weiter, unter Advanced > ACPI Settings:

NUMA                              [Enabled]
UMA-Based Clustering              [Hemisphere (2-clusters)]

NUMA steht für Non-Uniform Memory Access und beschreibt den Umstand, dass nicht jeder Speicherzugriff gleich lange dauert. Bei zwei Sockeln ist das offensichtlich: der eigene Speicher ist nah, der des Nachbarn geht über UPI und kostet spürbar mehr Zeit. Das Betriebssystem muss davon wissen, sonst legt es Daten und die Prozesse die damit arbeiten in verschiedene Ecken der Maschine.

Bei einem Sockel gibt es diese Unterscheidung nicht, und mein System meldet folgerichtig:

lscpu | grep NUMA
#   NUMA-Knoten:            1
#   NUMA-Knoten0 CPU(s):    0-15

Ein Knoten, alle sechzehn logischen Prozessoren darin. Warum steht der Schalter dann auf Enabled? Weil er nicht nur Knoten erzeugt, sondern die ACPI-Tabellen füllt, in denen die Topologie beschrieben wird. Die stehen bei mir vollständig zur Verfügung:

ls /sys/firmware/acpi/tables/ | grep -E "SRAT|SLIT|HMAT"
#   HMAT  SLIT  SRAT

SRAT ordnet Prozessoren und Speicherbereiche einander zu, SLIT beschreibt die Entfernungen zwischen den Knoten, HMAT geht noch weiter und beschreibt Bandbreiten und Latenzen. Bei einem Knoten ist der Inhalt langweilig, aber vorhanden. Auf Disabled würde das Betriebssystem schlicht weniger über die Maschine wissen, ohne dafür irgendetwas zu gewinnen.

Der Schalter mit dem sperrigen Namen

UMA-Based Clustering [Hemisphere (2-clusters)] ist die Zeile, an der ich beim ersten Lesen hängen geblieben bin. Um sie zu verstehen, muss man wissen, wie so ein Chip innen aussieht.

Bei Ice Lake sitzen Kerne, Cache-Scheiben und Speichercontroller in einem Gitter, dem Mesh. Jeder Zugriff wandert durch dieses Gitter. Meine CPU hat vier Speichercontroller mit je zwei Kanälen, macht acht, und das ist genau die Zahl meiner Speichermodule. Je nachdem wo im Gitter ein Kern sitzt, ist der eine Controller näher als der andere.

Hemisphere teilt den Chip in zwei Bereiche und sorgt über eine Hash-Funktion dafür, dass eine Speicheradresse der Cache-Scheibe zugeordnet wird, die auf derselben Seite des Chips liegt wie der zuständige Speichercontroller. Der Weg durchs Gitter wird kürzer. Nach aussen bleibt es ein einziger Speicherbereich, das Betriebssystem merkt nichts davon. Die Variante Quadrant macht dasselbe mit vier Bereichen.

Passend dazu steht im Uncore-Menü:

SNC (Sub NUMA)                    [Disable]

Sub-NUMA-Clustering ist die radikale Variante derselben Idee. Es meldet dem Betriebssystem tatsächlich mehrere NUMA-Knoten, obwohl nur eine CPU steckt, und überlässt ihm die Verteilung. Für eine Datenbank, die weiss was sie tut, kann das etwas bringen. Für einen Desktop bringt es Ärger, weil plötzlich wieder Prozesse und ihr Speicher auseinanderlaufen können.

Ich habe mit genau diesem Problem auf der alten Maschine genug Abende verbracht. Das lasse ich aus, und zwar mit Nachdruck.

Die Prefetcher zwischen den Sockeln

XPT Prefetch                      [Auto]
XPT Remote Prefetch               [Auto]
KTI Prefetch                      [Auto]
Stale AtoS                        [Auto]
LLC Dead Line Alloc               [Enable]
IO Directory Cache (IODC)         [Auto]
Snoop Throttle Configuration      [Auto]
Local/Remote Threshold            [Auto]

In Teil 3 ging es um fünf Prefetcher, die raten welche Daten ein Kern als nächstes braucht. Das hier ist dieselbe Idee eine Ebene höher: raten, welchen Weg eine Anfrage nehmen wird, und sie schon mal losschicken.

XPT Prefetch schickt eine Speicheranfrage parallel zur Cache-Abfrage direkt an den Speichercontroller. Stellt sich heraus, dass die Daten doch im Cache lagen, war es umsonst. Stellt sich heraus, dass sie es nicht taten, hat man die Cache-Suche geschenkt bekommen. KTI Prefetch macht dasselbe über die Sockelverbindung hinweg, XPT Remote Prefetch ebenfalls, und beide sind bei einem Sockel gegenstandslos.

LLC Dead Line Alloc ist die einzige Zeile hier, die nicht auf Auto steht. Dahinter steckt eine Aufräumfrage: wenn eine Zeile aus dem L2 verdrängt wird, soll sie dann in den gemeinsamen L3 wandern, obwohl sie vermutlich tot ist, also nie wieder gebraucht wird? Enable heisst hier ja, und für allgemeine Lasten ist das die richtige Wette.

Snoop Throttle bremst die Kohärenzabfragen, wenn das Gitter überlastet ist. IO Directory Cache merkt sich, welche Cache-Zeilen von PCIe-Geräten angefasst wurden, damit nicht bei jedem DMA-Zugriff alle Kerne gefragt werden müssen.

Bei all diesen Zeilen gilt dasselbe: Auto bedeutet, dass Intel für die erkannte Konfiguration sinnvolle Werte hinterlegt hat. Wer hier von Hand dreht, sollte einen Messaufbau haben und eine konkrete Vermutung. Ich habe beides nicht, und ich glaube nicht, dass ich mit Raten schlauer bin als die Leute die den Chip entworfen haben.

Zwei Zeilen die ich fast überlesen hätte

Link L0p Enable                   [Disable]
Link L1 Enable                    [Disable]

Das sind Stromsparzustände für die UPI-Verbindung. L0p schaltet einen Teil der Leitungen ab, L1 die ganze Verbindung. Beide kosten Zeit beim Aufwachen, und beide sind hier ohne Wirkung, weil es keine UPI-Verbindung gibt.

Ich erwähne sie trotzdem, weil sie ein schönes Beispiel für etwas sind, das durch die ganze Serie zieht: ein Server-BIOS zeigt einem alles, was das Board könnte, nicht das was die konkrete Maschine hat. Wer hier ohne diese Einordnung durchgeht, stellt Dinge ein, die schlicht niemanden interessieren.

Fazit

Die Uncore-Seite ist die Seite, an der ich am wenigsten geändert habe und am meisten gelernt. Zwanzig Einstellungen, davon stehen sechzehn auf Auto, und das ist auch gut so. Was bleibt, ist ein ziemlich direkter Blick darauf, wie so ein Chip innen organisiert ist: ein Gitter, Speichercontroller an verschiedenen Stellen, Cache dazwischen, und eine Menge Mechanik die versucht, Wege abzukürzen.

Nächste Folge: PCIe. Slots, Lanes, was Bifurcation ist, und warum eine Grafikkarte in einem x16-Steckplatz trotzdem nur acht Bahnen nutzt.

Siehe auch

• Teil 3 der Serie (die fünf Prefetcher eine Ebene tiefer)
• Teil 6 der Serie (der Speicher, an dem diese vier Controller hängen)

Falls jemand von euch SNC auf einem Ein-Sockel-Xeon eingeschaltet und dabei etwas Messbares gewonnen hat, würde ich das gerne lesen. Ihr dürft mich jederzeit fragen.

Willkommen bei Teil 5. Die bisherigen Folgen findest du gesammelt unter BIOS & Firmware. Heute geht es um Advanced > CPU Configuration > Advanced Power Management Configuration.

Advanced

Die Seite selbst ist kurz:

Power Technology                  [Custom]
Power Performance Tuning          [OS Controls EPB]
ENERGY_PERF_BIAS_CFG Mode         [Balanced Performance]
> CPU P State Control
> Hardware PM State Control
> Frequency Prioritization
> CPU C State Control
> Package C State Control
> CPU T State Control

Die erste Zeile ist wichtiger als sie aussieht. Power Technology kennt neben Custom noch Disable und Energy Efficient, und solange sie nicht auf Custom steht, sind die sechs Untermenüs Dekoration: die Firmware setzt dann ihre eigenen Werte und überschreibt, was man darunter einstellt. Wer sich also wundert, warum eine Änderung im C-State-Menü nichts bewirkt, sollte zuerst hier nachsehen.

Power Performance Tuning auf OS Controls EPB heisst, dass das Betriebssystem den Energy Performance Bias steuern darf und nicht das BIOS. Das ist genau das, was man auf einer Linux-Maschine will. Der dritte Wert ENERGY_PERF_BIAS_CFG Mode ist der Vorgabewert, den die Firmware setzt, solange sich niemand darum kümmert, und Balanced Performance ist dafür eine vernünftige Mitte.

P-States: die Frequenz

SpeedStep (P-States)              [Enable]
AVX P1                            [Nominal]
Dynamic SST-PP                    [Disable]
Intel SST-PP                      [Base]
Activate SST-BF                   [Disable]
Configure SST-BF                  [Enable]
EIST PSD Function                 [HW_ALL]
Turbo Mode                        [Enable]
CPU Flex Ratio Override           [Disable]
CPU Core Flex Ratio               23

SpeedStep ist der Klassiker: die CPU darf ihre Frequenz und Spannung an die Last anpassen. Intel nennt das seit Ewigkeiten EIST, Enhanced Intel SpeedStep Technology. Ohne diesen Schalter läuft der Prozessor stur auf Basistakt, verbraucht im Leerlauf deutlich mehr und wird wärmer, ohne dafür irgendetwas zurückzugeben. Der bleibt an.

Turbo Mode ist die Gegenrichtung: die CPU darf über den Basistakt hinaus, solange Temperatur und Stromaufnahme es hergeben. Bei meinem Xeon Gold 5315Y sind das 3,2 GHz Basis und 3,6 GHz Turbo. Linux bestätigt beide Enden:

lscpu | grep MHz
#   CPU max MHz:  3600,0000
#   CPU min MHz:   800,0000

EIST PSD Function auf HW_ALL regelt, wer die Frequenzwechsel koordiniert. Bei HW_ALL macht das die Hardware für alle Kerne einer Domäne selbst, bei SW_ALL müsste das Betriebssystem mitreden. Hardware ist hier schneller und weiss ohnehin mehr, das lässt man so. ALso ich, öhm. joar. 😀

Der Teil der mich überrascht hat: Speed Select

Mitten auf der Seite steht eine kleine Tabelle, die ich vorher noch nie in einem BIOS gesehen habe:

Intel SST-PP            Base | Config 3 | Config 4
  Core Count             08  |    06    |    04
  Current P1 Ratio [0]   32  |    32    |    34
  Package TDP (W)       140  |   125    |   115
  Tjmax                 103  |   100    |   101

Das ist Intel Speed Select Technology, Variante Performance Profile. Die Idee dahinter: dieselbe CPU kann in mehreren fest definierten Betriebspunkten laufen, und man wählt beim Booten aus, welchen man haben möchte. Meine hat drei. Im Auslieferungszustand Base sind es acht Kerne bei 3,2 GHz und 140 Watt. Wählt man Config 4, bleiben vier Kerne übrig, dafür steigt der Basistakt auf 3,4 GHz und die Verlustleistung fällt auf 115 Watt.

Man tauscht also Kerne gegen Takt, und zwar nicht per Turbo-Zufall, sondern als garantierte Zusicherung. Für Software, die pro Kern lizenziert wird, ist das bares Geld. Für Lasten, die nicht parallelisieren, sind 200 MHz mehr Basistakt spürbar. Und für mich? Ehrlich gesagt nutzlos. Ich habe acht Kerne gekauft, weil ich acht Kerne wollte, und 200 MHz sind kein Argument dafür, die Hälfte davon wegzuwerfen.

Trotzdem finde ich es bemerkenswert, dass so etwas in einem BIOS steht, das ansonsten aussieht wie 2005. SST-BF daneben ist die verwandte Idee auf Kernebene: Base Frequency, einzelne Kerne bekommen dauerhaft mehr Takt, die übrigen entsprechend weniger. Steht bei mir auf Disable, und das passt, denn dafür müsste ich meine Last gezielt auf die schnellen Kerne pinnen. Wer das tut, weiss warum. Wer es nicht tut, gewinnt nichts.

Und hier lag die Antwort

Hardware PM State Control
Hardware P-States                 [Disable]

Ein Untermenü mit genau einer Zeile, und diese Zeile hat mich mehr gefreut als der ganze Rest der Seite. Um zu erklären warum, muss ich kurz ausholen.

Seit dem Umbau ist mir aufgefallen, dass Linux die Frequenzsteuerung auf dieser Maschine anders macht als erwartet. intel_pstate, der Treiber der bei Intel-CPUs normalerweise das Kommando übernimmt, läuft hier im passiven Modus:

cat /sys/devices/system/cpu/intel_pstate/status        # passive
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver # intel_cpufreq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # schedutil

Passiv bedeutet: der Treiber verhält sich wie ein gewöhnlicher cpufreq-Treiber und lässt den Kernel-Governor entscheiden. Aktiv bedeutet, dass er die Entscheidung selbst trifft und dabei Hardware-Unterstützung nutzt. Aktiv ist normalerweise der bessere Modus, weil die CPU schneller reagiert als jeder Governor es könnte.

Der Kernel schaltet in den aktiven Modus, wenn die CPU HWP beherrscht, Hardware P-States. Ice Lake beherrscht das. Nur taucht das entsprechende Flag bei mir gar nicht auf:

grep -o hwp /proc/cpuinfo | head -1
#   (keine Ausgabe)

Ich hatte das eine Weile für eine Eigenheit des Kernels gehalten, für eine Frage der Xeon-Variante, für irgendetwas Kompliziertes. Es war nichts davon. Es war dieser eine Schalter, zwei Menüebenen tief in einem Untermenü, das ich beim ersten Mal nicht geöffnet hatte. Ich sag doch, ich bin auch nur doof.

Was tut HWP eigentlich? Ohne HWP sagt das Betriebssystem der CPU, welche Frequenz sie fahren soll. Mit HWP sagt es ihr nur noch, worauf es ihm ankommt, irgendwo zwischen Sparsamkeit und Leistung, und die CPU sucht sich den Rest selbst. Der Vorteil ist die Reaktionszeit: die Hardware sieht Lastwechsel im Mikrosekundenbereich, der Governor im Millisekundenbereich. Bei kurzen, stossweisen Lasten, wie sie ein Desktop dauernd produziert, macht das einen Unterschied.

Werde ich es umstellen? Vermutlich ja, aber nicht heute und nicht ohne Messung. Auf der alten Maschine hatte ich Ärger mit schedutil, der mir zu träge hochgetaktet hat, insofern habe ich eine Vermutung wohin es geht. Aber genau solche Vermutungen sind der Grund, warum man am Ende Dinge kaputtoptimiert. Erst messen, dann drehen.

C-States: das Nichtstun

Enable Monitor MWAIT              [Enable]
CPU C6 Report                     [Auto]
Enhanced Halt State (C1E)         [Enable]

P-States regeln, wie schnell die CPU arbeitet. C-States regeln, wie tief sie schläft wenn sie gerade nichts tut. Je höher die Nummer, desto mehr wird abgeschaltet und desto länger dauert das Aufwachen. Was auf meiner Maschine ankommt, steht im sysfs:

POLL   0 us
C1     1 us
C1E    4 us
C6   170 us

C6 ist der interessante: dort wird der Kernzustand weggeschrieben und der Kern faktisch abgeschaltet. Das spart richtig Strom, kostet aber 170 Mikrosekunden zum Aufwachen. Für einen Rechner unter dem Schreibtisch ist das vollkommen egal. Für einen Paketfilter, der Latenz im einstelligen Mikrosekundenbereich garantieren soll, ist es das nicht, und genau deshalb steht in Tuning-Anleitungen für Netzwerkkram regelmässig, man solle die tiefen C-States abschalten.

Enable Monitor MWAIT ist die Voraussetzung für den ganzen Mechanismus: MONITOR und MWAIT sind die beiden Befehle, mit denen ein Kern sagt „weck mich, wenn sich diese Speicherstelle ändert“ und sich danach schlafen legt. Ohne sie bleibt nur die alte HLT-Schleife.

Package C State [Auto] eine Menüebene weiter ist die Steigerung davon: nicht mehr einzelne Kerne, sondern das ganze Paket samt Uncore und Speichercontroller. Das geht natürlich nur, wenn wirklich alle Kerne gleichzeitig nichts tun.

T-States, und warum sie aus sind

Software Controlled T-States      [Disable]

Der dritte Buchstabe im Bunde, und der unangenehmste. T-States drosseln nicht die Frequenz, sondern schieben Pausen ein: die CPU bekommt für einen Teil der Zeit schlicht keinen Takt. Das ist deutlich brutaler als ein P-State und eigentlich eine Notbremse für den Fall, dass es zu heiss wird.

Auf Disable heisst, dass das Betriebssystem diese Notbremse nicht selbst ziehen darf. Der thermische Schutz der Hardware bleibt davon unberührt, der arbeitet unabhängig weiter. Bei Tjmax 103 Grad und CPU-Temperaturen um die 40 im Leerlauf ist das eine sehr theoretische Diskussion.

Der Rest

Frequency Prioritization
RAPL Prioritization               [Disable]

RAPL ist Intels Mechanismus zur Leistungsbegrenzung. Mit RAPL Prioritization verteilt die Firmware ein knappes Leistungsbudget gezielt auf einzelne Kerne, statt alle gleichmässig zu drosseln. Das ergibt Sinn, wenn man dauerhaft am Powerlimit fährt und weiss, welche Kerne die wichtige Arbeit machen. Meine Maschine ist von beidem weit entfernt.

Was ich mitnehme

Der ganze Block ist erstaunlich gut eingestellt für ein Board, das im Auslieferungszustand von einem Serverhersteller kam. SpeedStep an, Turbo an, C-States an, T-States aus, das würde ich genau so einstellen. Ob da Supermicro oder Thomas Krenn sich Mühe gegeben hat?

Der einzige echte Fund ist Hardware P-States [Disable]. Und der ist vor allem deshalb schön, weil er zeigt, wozu so ein Durchgang gut ist: ich habe seit Wochen ein Verhalten beobachtet, das mich gewundert hat, und die Ursache lag die ganze Zeit sichtbar in einem Menü. Ich musste nur hineinschauen.

Nächste Folge: der Speicher. ECC, Patrol Scrub, PPR, und die Frage warum 256 GB DDR4-3200 in dieser Maschine mit 2933 laufen, klingt ja falsch oder?

Siehe auch

• Teil 3 der Serie (Kerne, Threads und die fünf Prefetcher)
• Teil 4 der Serie (AES-NI, SGX und ein Schalter der nichts bewirkt)

Falls jemand von euch intel_pstate im aktiven Modus gegen schedutil gemessen hat, auf einem Xeon und nicht auf einem Notebook: erzähl mir davon, bevor ich es selbst ausprobiere. Ihr dürft mich gerne fragen.

Ein Detail, das mich an dieser Maschine bis heute amüsiert: die Kiste, die hier steht, hat weniger Kerne als die, die sie ersetzt hat. Vorher waren es zwei Xeon E5-2687W v3, zusammen 20 Kerne und 40 Threads. Jetzt ist es ein einzelner Xeon Gold 5315Y mit 8 Kernen und 16 Threads. Auf dem Papier ein deutlicher Rückschritt, in der Praxis für fast alles was ich mache ein Fortschritt, weil jeder einzelne Kern erheblich mehr leistet und weil PCIe 4.0 und 256 GB Speicher am Ende mehr wert sind als zwölf zusätzliche langsame Kerne.

Womit wir bei der Seite wären, um die es heute geht. Das hier ist die dritte Folge meiner Reise durch das BIOS dieses Supermicro-Boards, alle Teile stehen gesammelt unter BIOS & Firmware. Dran ist Advanced > CPU Configuration, und zwar die obere Hälfte. Die untere mit AES-NI, SGX und den Sicherheitsfunktionen bekommt die nächste Folge, sonst wird es zu lang.

Der Teil zum Anschauen

Oben auf der Seite steht ein Block, an dem man nichts einstellen kann. Trotzdem lohnt sich der Blick, weil dort Dinge stehen, die man sonst zusammensuchen müsste:

Processor BSP Revision          606A6 - ICX M1
Processor ID                    000606A6
Processor Frequency             3.200GHz
Processor Max Ratio             20H
Processor Min Ratio             08H
Microcode Revision              0D000421
L1 Cache RAM(Per Core)          80KB
L2 Cache RAM(Per Core)          1280KB
L3 Cache RAM(Per Package)       12288KB

606A6 ist die Prozessorsignatur, aufgedröselt: Familie 6, Modell 6A, Stepping 6. ICX M1 ist Intels interne Bezeichnung dafür, ICX steht für Ice Lake. Die beiden Ratios sind Multiplikatoren in hexadezimal, 08H sind 8 und 20H sind 32. Mit dem üblichen Referenztakt von 100 MHz ergibt das 800 MHz im Leerlauf und 3,2 GHz als Basistakt. Genau diese Spanne meldet auch Linux:

lscpu | grep MHz
#   CPU max MHz:  3600,0000
#   CPU min MHz:   800,0000

Die 3600 oben drüber sind der Turbo, der geht über den Basisratio hinaus. Dazu mehr, sobald ich das Power-Management-Menü nachgereicht bekomme, das fehlt mir in meiner Aufzeichnung noch.

Am interessantesten finde ich die Cache-Zeilen. 1280 KB L2 pro Kern klingt viel, und das ist es auch. Bei Ice Lake hat Intel den L2 gegenüber der Vorgängergeneration deutlich aufgebohrt und im Gegenzug den gemeinsamen L3 kleiner gemacht. 12 MB L3 für acht Kerne sind für einen Xeon nicht üppig. Der Gedanke dahinter ist, dass Daten näher am Kern liegen und seltener über den Ring wandern müssen. Ob das für die eigene Last aufgeht, merkt man erst beim Messen, aber die Zahlen im Setup erzählen die Designentscheidung ziemlich direkt.

Das Microcode Revision 0D000421 ist übrigens der Wert, den auch Linux meldet:

grep -m1 microcode /proc/cpuinfo
#   microcode : 0xd000421

Das BIOS bringt also bereits den Mikrocode mit, den auch das Betriebssystem laden würde. Wer sich fragt, ob ein BIOS-Update wegen Mikrocode nötig wäre: hier eindeutig nein.

Kerne abschalten, in hexadezimal

> CPU1 Core Disable Bitmap

Ein eigenes Untermenü mit genau einem Eintrag, und dieser Eintrag ist herrlich unhöflich. Das Handbuch beschreibt ihn so:

Select 0 to enable all cores or FFFFFFFFFFF to disable all cores. One core must be enabled.

Man gibt also eine Bitmaske in hexadezimal ein, in der jedes gesetzte Bit einen Kern abschaltet. Keine Auswahlliste, keine Zahl „wie viele Kerne hätten Sie gern“, eine Bitmaske. Und dann der wunderbare Nachsatz, dass mindestens ein Kern übrig bleiben muss, was man vermutlich nicht schreiben würde, wenn es nicht mal jemand ausprobiert hätte.

Wozu macht man so etwas? Der häufigste Grund ist Lizenzkosten. Es gibt genug Software, die pro Kern abgerechnet wird, und wenn eine Maschine dafür zu viele hat, schaltet man welche ab. Der zweite Grund ist Testen: Verhalten einer Anwendung auf weniger Kernen prüfen, ohne die Hardware zu tauschen. Bei mir steht das erwartungsgemäss auf 0, alle 16 logischen Prozessoren sind da:

cat /sys/devices/system/cpu/online     # 0-15
cat /sys/devices/system/cpu/offline    # leer

Wichtig zu verstehen ist der Unterschied zum Abschalten unter Linux. Wenn ich dort einen Kern offline nehme, existiert er weiter, er bekommt nur keine Arbeit mehr. Die Bitmaske im BIOS blendet ihn aus, bevor das Betriebssystem überhaupt startet. Für eine Lizenzzählung, die sich ansieht was die Maschine meldet, ist das ein Unterschied.

Hyper-Threading

Hyper-Threading [ALL]           [Enable]

Der bekannteste Schalter der Seite. Aus acht physischen Kernen werden sechzehn logische, weil jeder Kern zwei Befehlsströme gleichzeitig verwaltet und die Recheneinheiten teilt, die gerade nichts zu tun haben. Der Gewinn liegt je nach Last irgendwo zwischen nichts und dreissig Prozent.

Es gibt drei gute Gründe, das abzuschalten, und keiner davon trifft auf mich zu. Der erste sind Seitenkanalangriffe: mehrere der Spectre-Nachfolger nutzen aus, dass sich zwei Threads einen Kern teilen, und wer fremden Code auf seiner Maschine ausführen lässt, fährt ohne Hyper-Threading sicherer. Der zweite ist Latenz: bei harten Echtzeitanforderungen ist ein Kern, der sich mit niemandem abstimmen muss, berechenbarer. Der dritte sind wieder Lizenzen.

Für eine Workstation, auf der ich weiss was läuft, überwiegt der Durchsatz. Bleibt an.

Die fünf Prefetcher

Und jetzt der Teil, der wirklich interessant ist:

Hardware Prefetcher             [Enable]
Adjacent Cache Prefetch         [Enable]
DCU Streamer Prefetcher         [Enable]
DCU IP Prefetcher               [Enable]
LLC Prefetch                    [Enable]

Fünf Zeilen, die aussehen wie eine Liste von Marketingbegriffen und in Wirklichkeit fünf verschiedene Stücke Hardware beschreiben. Alle haben dieselbe Aufgabe: raten, welche Daten die CPU als nächstes braucht, und sie schon mal holen. Speicher ist quälend langsam gegenüber dem Prozessor, ein Zugriff der bis zum RAM durchschlägt kostet ein Vielfaches dessen, was aus dem Cache kommt. Jeder erfolgreiche Rateversuch spart diese Wartezeit.

Sie raten nur unterschiedlich:

• Hardware Prefetcher ist der Streaming-Prefetcher für den L2. Er erkennt, dass ein Programm Speicher der Reihe nach durchläuft, und holt vorausschauend nach. Der klassische Fall ist eine Schleife über ein grosses Array.
• Adjacent Cache Prefetch ist der simpelste von allen. Er holt zu jeder angeforderten 64-Byte-Cachezeile gleich die benachbarte mit, arbeitet also faktisch in 128-Byte-Blöcken. Die Wette lautet: wer diese Zeile braucht, braucht gleich auch die daneben.
• DCU Streamer Prefetcher macht dasselbe wie der erste, aber eine Ebene näher am Kern, für den L1-Datencache. DCU steht für Data Cache Unit.
• DCU IP Prefetcher ist der cleverste. IP steht hier für Instruction Pointer. Er merkt sich pro Befehl, welche Zugriffsmuster dieser Befehl in der Vergangenheit erzeugt hat, und extrapoliert daraus. Damit erwischt er auch Muster mit konstantem Abstand, etwa jedes achte Element einer Struktur, an denen ein reiner Streaming-Prefetcher scheitert.
• LLC Prefetch zieht Daten in den gemeinsamen L3, den Last Level Cache.

Das Handbuch beschreibt den DCU IP Prefetcher übrigens als etwas, das „IP addresses“ vorlädt und damit „network connectivity“ verbessert. Das ist schlicht falsch, da hat jemand Instruction Pointer mit Internet Protocol verwechselt und den Satz nie wieder gelesen. Solche Sätze stehen in erstaunlich vielen Handbüchern, und sie sind eine gute Erinnerung daran, dass auch offizielle Dokumentation nur von Menschen geschrieben wird.

Die Gegenprobe: was davon kommt wirklich an

Das Schöne an diesen fünf Schaltern ist, dass man sie nicht glauben muss. Sie landen in einem Prozessorregister, und das kann man auslesen. MSR 0x1A4 heisst Prefetch Control, und die unteren vier Bits schalten die Prefetcher ab, wenn sie gesetzt sind:

modprobe msr
rdmsr -0 0x1a4
#   0000000000000000

Null. Kein Bit gesetzt, also kein Prefetcher abgeschaltet. Das deckt sich exakt mit dem, was das Setup anzeigt. Die Zuordnung ist Bit 0 für den Hardware Prefetcher, Bit 1 für Adjacent Cache Line, Bit 2 für den DCU Streamer und Bit 3 für den DCU IP Prefetcher. Man beachte die umgekehrte Logik: gesetztes Bit bedeutet aus.

Ich mag solche Gegenproben. Ein Screenshot zeigt, was das Setup behauptet. Das Register zeigt, was die CPU tatsächlich macht. Bei Firmware ist das nicht immer dasselbe.

Wann man daran drehen würde

Fast nie, ehrlich gesagt. Die Prefetcher sind für allgemeine Lasten deutlich im Plus, sonst hätte Intel sie nicht eingebaut. Es gibt aber Fälle, in denen sie schaden:

Bei Datenbanken und Graphen-Workloads mit stark zufälligem Zugriffsmuster liegt der Prefetcher regelmässig daneben, holt Daten die keiner braucht, und verdrängt dabei Daten die jemand gebraucht hätte. Bei Echtzeitanwendungen sind sie eine Jitter-Quelle, weil sie Speicherbandbreite zu unvorhersehbaren Zeitpunkten verbrauchen. Und bei manchen HPC-Codes, die ihre Zugriffe selbst sehr genau steuern, stört der Prefetcher mehr als er hilft.

Der entscheidende Punkt: das misst man, das rät man nicht. Und der grosse Vorteil des MSR ist, dass man dafür gar nicht ins BIOS muss. Man kann die Bits im laufenden System setzen, messen, und wieder zurücksetzen. Wer das ernsthaft ausprobiert, sollte allerdings wissen, dass wrmsr genau so gefährlich ist wie es klingt, und dass die Einstellung pro logischem Prozessor gilt.

Nächste Folge: die untere Hälfte derselben Seite. AES-NI, TME, SGX und ein Schalter namens Extended APIC, der aussieht wie eine vergessene Optimierung und keine ist.

Siehe auch

• Teil 2 der Serie (Boot Feature, und ein Interrupt von 1981)
• Intel QuickAssist 8950-SCCP (wenn die CPU etwas nicht kann, und eine Karte einspringt)

Hat jemand von euch schon mal Prefetcher gezielt abgeschaltet und dabei etwas gemessen, das sich gelohnt hat? Das würde mich wirklich interessieren, ihr dürft mich jederzeit fragen.