In der Nacht vom 16. auf den 17. August erschien die zweite Reinkarnation der 7er Reihe des Linux-Kernels. In seiner obligatorischen Release-Mail beklagt Linus Torvalds die letzte Woche vor der Freigabe von 7.2 als viel arbeitsintensiver als erwartet. Früher hätte dies sicherlich zu einer Verzögerung geführt – sprich, mindestens zu einer weiteren Woche Entwicklungszeit. Wenn er das jedoch gemacht hätte, wäre wohl nie ein neuer Kernel freigegeben worden. Augenzwinkernd oder nicht sei dahingestellt. Fakt ist, es gab eine Reihe an kurz vor Schluss zurückgenommener Änderungen.
Prominentestes Beispiel sind Änderungen am Scheduling im Direct Rendering Manager (DRM). Dort war ein Wechsel des GPU-Schedulers (Graphics Processing Unit) von einem einfachen FIFO-Prinzip hin zu einer faireren Laufzeitverteilung geplant. Dieses als bedeutende Verbesserung herausgestellte Feature sollte der neue Standard sein. Doch es geht nun auf die Wartebank – zumindest als Voreinstellung.
Trotz des Zurückruderns enthält Linux 7.2 einige interessante Neuerungen. Einige davon greifen wir hier im Nachgang zum Release des neuen Kernels auf.
Faires GPU-Scheduling
Der neue GPU-Scheduler orientiert sich konzeptionell an dem alten Completely Fair Scheduler (CFS) für Prozesse. Der CFS sorgte damals für eine faire Verteilung der CPU-Zeit. Statt Prozesse auf CPUs zu verteilen wie der CFS, sorgt der GPU-Scheduler dafür, dass jede Anwendung anteilig bei der GPU mal zum Zuge kommt.
Bislang verwendete dieser hierzu das FIFO-Prinzip (First In First Out). Die Anwendungen stellen Anfragen als GPU-Jobs in eine Warteschlange, die der Scheduler nach und nach abarbeitet. Wer zuerst kommt oder viele Anfragen stellt, bekommt die meiste Rechenzeit. Das ist nicht immer so gewünscht. Linux 7.2 führt nun ein faireres Scheduling beim Verteilen der verfügbaren GPU-Ressourcen ein.
Der DRM-Scheduler verwaltet dabei sogenannte Scheduling Entities, die die GPU-Jobs enthalten. Jeder Entity weist der Scheduler eine virtuelle Laufzeit zu. Je mehr GPU-Zeit eine Entity verbraucht, umso schneller steigt dieser Wert. Beim Verteilen der GPU-Ressourcen bevorzugt der Scheduler jeweils die ausführbare Entity mit der niedrigsten virtuellen Laufzeit. Auf diese Weise rücken Anwendungen, die bislang wenig GPU-Zeit erhalten haben, automatisch nach vorn.
Prioritäten neu gemischt
Um Anwendungen zu priorisieren, kennt das FIFO-Prinzip strikt getrennte Priority-Queues. Hoch priorisiertes wurde bevorzugt mit GPU-Zeit bedient. Niedrig priorisiertes kam womöglich gar nicht an die begehrten GPU-Ressourcen.
Der neue DRM-Scheduler will das vermeiden, indem die Priorität einer Entity ins Berechnen der virtuellen Laufzeit als gewichtender Faktor einfließt. Je niedriger die Priorität, desto höher dieser Faktor. Dadurch sammelt eine Low-Priority-Entity schneller virtuelle Laufzeit an als eine hoch priorisierte Entity. Entsprechend seltener erhält die niedrig priorisierte GPU-Zeit. Sie wird aber nicht grundsätzlich ausgehungert. Damit verhindert der faire Ansatz die „Priority Starvation“, bei der niedrig priorisierte Anwendungen unter Dauerlast theoretisch unbegrenzt warten können.
Davon sollen kurze, interaktive GPU-Lasten profitieren. Ein Desktop-Compositor benötigt beispielsweise nur in kurzen Abständen wenig GPU-Zeit. Ein Spiel oder eine KI kann hingegen die GPU nahezu vollständig auslasten. Unter FIFO können tiefe Queues eines rechenintensiven Clients so den Desktop scheinbar einfrieren lassen. Der Fair-Ansatz erkennt hingegen indirekt, dass der Compositor bislang wenig GPU-Zeit verbraucht hat und bevorzugt ihn entsprechend.