Schneller und weniger oft zum Kernel
Ziel der Maßnahme gegen Meltdown ist es, den Adressraum des Kernels möglichst weitgehend von dem einer Userspace-Anwedung zu trennen. Unter Windows wird diese Technik als Kernel Virtual Adress (KVA) Shadow bezeichnet und unter Linux als Page Table Isolation (PTI).
Bisher war der Kernel standardmäßig in den Userspace gemappt, um einen Kontextwechsel zwischen Kernelspace und Userspace schneller durchführen zu können und den Translation Lookaside Buffer (TLB) hierbei nicht leeren zu müssen. Die CPU sorgt eigentlich für die dennoch notwendige strikte Trennung zwischen Kernel- und Userspace, was bei Meltdown allerdings geschickt umgangen wird.
Der Kernel wird mit den Patches nicht mehr so gemappt wie bisher, was dazu führt, dass der TLB bei einem Wechsel des laufenden Prozesses vom User- in den Kernelspace geleert wird und auf dem Rückweg ebenfalls. Dieses neue Verhalten führt damit allerdings zwangsläufig zu einem Leistungsverlust und ist genau deshalb auch bisher vermieden worden.
Systemaufruf und Kontextwechsel sind teuer
In einem völlig synthetischen Benchmark, auf den der Linux-Entwickler Dave Hansen in seinen PTI-Patches verweist, fällt die Rate zum wiederholten Aufrufen des Systemaufrufs lseek von 5,2 Millionen Aufrufen je Sekunde auf 2,2 Millionen Aufrufe bei Verwendung der PTI-Patches.
In ähnlichen Tests des Netflix-Angestellten Brendan Gregg zeigt sich darüber hinaus, dass sich die Leistungseinbußen mit steigender Anzahl der Systemaufrufe sogar noch vergrößern könnten. Bei 10 Millionen Systemaufrufen je Sekunde und CPU liegt der Leistungsverlust demnach gar bei 400 Prozent. Ähnliche Erkenntnisse liefert Gregg auch für Kontextwechsel: Je mehr diese vorkommen, desto größer ist der Leistungsverlust.
Greift ein Programm außerdem häufig auf einen vergleichsweise großen Bereich des Arbeitsspeichers zu (Working Set Size) und kommt es hierbei möglicherweise gar zum Auslagern des Speicherbereiches, sind die Leistungseinbußen entsprechend noch größer. Denn schlimmstenfalls versucht ein Programm dann auf nicht im Arbeitsspeichers befindliche Speicherbereiche zuzugreifen. Solch ein Seitenfehler verursacht eine Programmunterbrechung und das Neuladen des notwendigen Speicherbereichs.
Für Linux-Nutzer relativ leicht nachvollziehen lassen sich diese Ergebnisse mit kleinen Werkzeugen wie stress-ng, die es ebenfalls ermöglichen, das System mit dauerhaften Systemaufrufen oder auch Kontextwechseln - wie der Name sagt - zu stressen. Damit lassen sich ebenso absurd hohe Leistungseinbußen ermitteln. Aussagekräftig oder gar relevant ist das aber nicht.
So schreibt etwa Gregg, dass die typische Rate von Systemaufrufen der Anwendungen von Netflix bei etwa 10.000 pro Sekunde und CPU liege. Der damit verbundene Leistungsverlust ist also mehr oder weniger vernachlässigbar. Eine Reduktion und eventuell auch Überprüfung der Anzahl der Systemaufrufe ist aber eigentlich immer angebracht, auch völlig unabhängig von Meltdown. Und die möglichen und tatsächlich genutzten Optimierungen spielen hierbei noch gar kein Rolle.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Meltdown- und Spectre-Benchmarks: Weniger schlimm als erwartet | Verbesserungen in Kernel und Anwendungen |
Ein Block aus 8 reservierten CVEs ist nicht das Gleiche wie 8 Sicherheitslücken. Abwarten...
Kann mir nicht vorstellen, dass der Ryzen 2700x weniger IPC als deine CPU hat.
Bei meinem Haswell i5-4200U merke ich eigentlich nichts beim täglichen Benutzen. Wenn...
Bei top ist das tatsächlich ganz genau so.