Fragen? Antworten! Siehe auch: Alternativlos
Die Benchmark-Parameter waren:
./bench -n 1000 -c 10 -k -K 5 http://127.0.0.1/testfileDas heißt: 1000 Mal diese Datei laden, über 10 Verbindungen parallel, mit 5 Downloads pro TCP-Verbindung via HTTP-Keepalive. Sowohl das Benchmark-Tool als auch gatling sind Single-Threaded und laufen auf jeweils einem Core nebeneinander. Es sollte also nicht zu vielen Context Switches kommen, aber natürlich sehr viele Wechsel vom User Space in den Kernel und zurück. Und die sind genau das, was durch den Fix langsamer werden. Die CPU ist ein Haswell (noch ohne Microcode-Update). Das sollte also ziemlich nahe am Worst Case sein. Und in der Tat. Mit dem alten Kernel:
bench: 164835678432 bytes in 24.7616 seconds. bench: Throughput: 6.2GiB/sec bench: Requests per second: 40und mit dem neuen Kernel:
bench: 164870699232 bytes in 39.3921 seconds. bench: Throughput: 3.9GiB/sec bench: Requests per second: 25Das ist ein ziemlich krasser Einbruch. Und da ist kein SSD beteiligt, das ist alles Buffer Cache ohne tatsächlichen I/O zu tatsächlicher Hardware.
Update: Nach Einspielen des neuen Microcodes wird es ein bisschen weniger schlimm (4.5GiB/sec), aber das ist immer noch katastrophal viel schlechter als vorher. Kann mir mal jemand erzählen, wieso das jetzt keinen Recall gibt?
Ich hatte übrigens den 4.15 mit Retpoline-Support gebaut, aber ohne einen gcc mit Retpoline-Support. Laut Dokumentation werden dann von Hand an einigen Stellen Assembler-Fixes eingebaut.
Update: Intel hatte den Microcode zurückgezogen. Stellt sich raus: Das Microcode-Update, das ich probiert habe, war gar nicht der Meltdown-Fix. Hatte mich schon gewundert, wieso da 2017 dran stand. Damit ist der Unterschied zwischen den 3,9 und den 4,5 GiB/sec anscheinend Messvarianz Messfehler.
Update: Ach und der gcc 7.3, mit dem ich den Kernel gebaut hatte, kann doch Retpolines. Haben sie nur nicht für relevant genug gehalten, um es im Changelog online zu erwähnen.
Update: Haswell ist gar nicht der Worst Case, wie sich rausstellt. Ich habe schon pcid und invpcid im /proc/cpuinfo. Bei Sandy Bridge und co ist das wohl noch deutlich schlimmer.