News Linux Kernel 6.13: Leistungsoptimierungen und AMD 3D V-Cache Optimizer

[metoer]

Aus AutoFDO werde ich nicht ganz schlau, soll das nur das kompilieren des Kernels beschleunigen oder hat ein damit kompilierter Kernel dann auch im betrieb performance Vorteile?

 

[stefan92x]

@metoer Das kompilieren wird damit nicht beschleunigt, nur der spätere Betrieb. Der Ablauf dabei ist halt letztlich folgender:

• du kompilierst den Kernel
• du betreibst ihn und erhebst Statistiken zur Nutzung (in einem realitätsnahen Testsystem oder gleich einem Teil der produktiven Server)
• du kompilierst den Kernel nochmal und nutzt die erfassten Statistiken zur Optimierung (welche Codepfade sollen bevorzugt behandelt werden etc).
• du betreibst den optimierten Kernel produktiv

 

[ptr1337]

@ptr1337 Danke für die Infos! Ich frage jetzt einfach mal, wird der Patch für den Cache Optimizer in die CachyOS Kernel übernommen?

Ja, der is im 6.13 linux-cachyos kernel hier:
https://github.com/CachyOS/kernel-patches/blob/master/6.13/0007-itmt-core-ranking.patch


Wir werden den kernel bald pushen, falls keine großen Bugs gefunden werden im finalen testen. Generell scheint der Kernel in der RC Phase relativ stabil gewesen zu sein.

Wir hatten den 3D Cache Optimizer + preffered core fixes schon in dem 6.12 Kernel, daher haben wir es in unser Wiki geschrieben.

Ergänzung (20. Januar 2025)

Aus AutoFDO werde ich nicht ganz schlau, soll das nur das kompilieren des Kernels beschleunigen oder hat ein damit kompilierter Kernel dann auch im betrieb performance Vorteile?

Ist was ähnliches wie "PGO" --> Profile Guided Optimization.

Man compiled den Kernel mit paar extra optionen, um das profilieren von den Kernel besser und einfacher zu machen. Dieses Profil wird dann konvertiert, damit der Compiler es "verstehen" kann und damit optimiert er den Code.
Das resultiert in weniger Cache und Instruction Misses, welches dann in mehr Performance für den kernel resultiert.

Google sprich von deren Workload mit der Propeller und AutoFDO Optimierung von rund 10% mehr Durchsatz.

Wir haben bei CachyOS AutoFDO "optimized" seit 6.12 ausgerollt und mit 6.13 werde ich zusätlich die Propeller Optimierung hinzufügen.

Schau dir gerne mal den Guide an, welchen ich geschrieben habe - eventuell wird es damit auch klarer:
https://cachyos.org/blog/2411-kernel-autofdo/

 

[metoer]

@stefan92x @ptr1337
Danke für die Aufklärung!

 

[Pesky_]

CachyOS Wiki

Schön, das sie da schneller als das Arch Wiki sind, aber die Codeausschnitte in hellem grau auf hellem blau zu machen ist wunderschön unleserlich.

 

[ptr1337]

@Pesky_ Leider ist derzeit das Code Highlighting "kaputt" weil eine Dependecy vom astro kaputt ist. Sollte aber bald gefixed sein

 

[Pesky_]

Sollte aber bald gefixed sein

Gut zu wissen.
PS: Wie schlägt sich deine 4070 Super unter Linux so? Höre da Horrorgeschichten von einem Kollegen.
Habe selbst noch eine RX6700XT, also keine Probleme.

 

[ptr1337]

@Pesky_ Ich habe mit der 4070 Super wenig Probleme. Hier und da sind ein paar "nervige" Sachen z.B:

• Multi Monitor VRR geht nicht, generelles Treiber Problem, wird gefixed mit dem Treiber zusammen mit dem Blackwell Release
• Shared Memory (RAM/VRAM) scheint nicht gut oder gar nicht zu funktionieren

Ansonsten habe ich generell ein gute Erfahrung und ich nutze nur Wayland seit knapp 2 Jahren (davor 1070 Ti). Dies hat sich deutlich verbessert seit dem 555 Treiber und seit her ist Wayland sehr gut.


Generell kommt es derzeit massiv auf die Konfiguration des Treiber an, ob du eine gute Erfahrung hast oder nicht. (Wayland OOB, Sleep, ...)

CachyOS konfiguriert dies out of the box - andere distributionen machen es nicht. Fedora (RPM Fusion) macht es mittlerweile auch, und zu archlinux habe ich es auch gepushed.

Distributionen wie Ubuntu sind mit NVIDIA ohne eigene Hand vermutlich "solala" da auch ältere Treiber.

 

[Deinorius]

Es ist schade, dass noch keiner richtige Benchmarks zu NTSync durchgeführt hat. Im Phoronix Forum gibt es einen Eintrag mit CP2077 und dem v5 patch (aktuell ist v7), wo der Unterschied gewaltig zu sein scheint, aber keine Ahnung, was man davon halten soll. Auf YouTube gibt es einen, der mehrere Benchmarks durchgeführt hat und während in CP2077 a bisserl größere Unterschiede zu erkennen waren, haben andere Spiele kaum welche gezeigt.
Letzten Endes braucht ein Review mit mehreren Spielen, hoffentlich auch mit zusätzlich schwächerer Hardware, um aufzuzeigen, welche Spiele wo einen besonderen Vorteil mit NTSync bekommen. Und dann natürlich ein Vergleich mit Windows.

 

[Pummeluff]

Bzgl ReiserFS:

… seinen Brief aus dem Hochsicherheitsgefängnis (Nov 2023) an die Linux Kernel Mailing List, oder einen Bericht zu jenem Brief.

Hab's mal überflogen. Man merkt halt, dass der Mann nicht wirklich viele Beschäftigungen hat. Wenn er irgendwann mal aus dem Knast kommt, dürfte die Geschichte um sein Vermächtnis sehr schwierig für ihn zu ertragen sein, wenn er mitbekommt, dass seine Arbeit komplett tot ist. Er schreibt ja einige Male von Reiser V5 in der Hoffnung, dass seine damaligen Angestellten das Projekt weitergeführt haben könnten.

Ich hatte zu Suse 9.x Zeiten ein einziges Mal reiserfs auf der root Partition im Einsatz, weil das damals die Standardauswahl war. Das war dann auch meine bislang einzige Linux installation, die durch ein korrumpiertes Dateisystem irreparabel kaputt ging. Mit ext oder XFS gab es nie derartige Probleme, gut dass der Reiser Mist jetzt endgültig beerdigt wurde.

Tja, mir ging's genau andersrum. Reiser3 hatte zwar Fragmentierungsprobleme, d.h. wurde langsamer mit der Zeit. Aber Datenverluste hatte ich nie. Und Reiser4 hatte ich sogar als Root-Partition. War mühsam, immer den Kernel zu patchen und vor allem zu warten, bis Edward Shishkin den Patch für den jeweiligen Kernel angepasst hatte. Mit dem hatte ich damals sogar einige Male Kontakt per E-Mail deswegen. Im Log hat's da so einige Meldungen gegeben. Aber Datenverlust hatte ich damit nie.

Im Gegensatz dazu hatte ich XFS mal auf meinem ARM-Nas eingesetzt. Das hat mir nach sehr kurzer Zeit die ganze Datenpartition vernichtet. Ich denke, das Problem wird schon lange gelöst sein. Auf Arbeit haben wir es im Serverbereich im großflächigen Betrieb problemlos eingesetzt. Als ich mir vor 5 Jahren mein Nachfolge-NAS (auch wieder auf ARM-Basis) geholt hab, hab ich trotzdem lieber ext4 eingesetzt.

Während ReiserFS halt eher auf dem Stand von ext2/ext3 ist, gibt es z.B. seit vielen Jahren schon ext4 als weiterentwickeltes Standard-Dateisystem

Etwas unglücklich ausgedrückt. Wenn du ReiserFS mit ext2/3 vergleichst, dann solltest du ext4 auch mit Reiser4 gleichsetzen.

Reiser4 war damals ein echt cooles Dateisystem. Es war eigentlich auch fertig, ein paar Userspace-Tools hatten noch gefehlt.

Nachdem Hans Reiser in den Knast ging und der Niedergang der Firma langsam abzusehen war, analysierte Edward Shishkin, einer der Hauptentwickler von Reiser4, mal BTRFS im Auftrag von Redhat. Das wurde damals gerade aus der Taufe gehoben und sprang praktisch in die Lücke, die Reiser4 hinterließ. Er fand damals in BTRFS grundsätzliche Design-Fehler. Es dauerte auch noch viele Jahre, bis BTRFS dann mal stabil nutzbar wurde.

Wie man aus meinem Text heraushört, trauer ich Reiser4 durchaus nach. Lässt sich schwierig sagen, an welchem Punkt wir heute wäre, wenn es tatsächlich Reiser5 hätte geben können. Aber hätte, hätte, Fahrradkette…

Und wer noch mehr Zeit zum Lesen hat, kann sich ja mal den Golem-Artikel dazu durchlesen.

 

[ptr1337]

Es ist schade, dass noch keiner richtige Benchmarks zu NTSync durchgeführt hat. Im Phoronix Forum gibt es einen Eintrag mit CP2077 und dem v5 patch (aktuell ist v7), wo der Unterschied gewaltig zu sein scheint, aber keine Ahnung, was man davon halten soll. Auf YouTube gibt es einen, der mehrere Benchmarks durchgeführt hat und während in CP2077 a bisserl größere Unterschiede zu erkennen waren, haben andere Spiele kaum welche gezeigt.
Letzten Endes braucht ein Review mit mehreren Spielen, hoffentlich auch mit zusätzlich schwächerer Hardware, um aufzuzeigen, welche Spiele wo einen besonderen Vorteil mit NTSync bekommen. Und dann natürlich ein Vergleich mit Windows.

Wir haben ein Proton gemacht, welches NTSync enthält. Es ist leider nicht perfekt, daher haben wir es nicht in das default "proton-cachyos" bis jetzt gemacht.
Falls du aus der "AUR" ntsync-dkms installierst, kannst du es nutzen.
https://github.com/CachyOS/proton-cachyos/releases/tag/cachyos-9.0-20250102-slr

NTSync kann man mit "PROTON_ENABLE_NTSYNC=1" anmachen. Ein paar Probleme gibt es in den NTSync code noch, weil einige Spiele nicht starten.
Ebenfalls gibt es probleme mit dem derzeitigen Code von uns für Proton, welches Fsync (futex wait v) probleme machen kann. Dies war der Hauptgrund warum wir es nicht gemerged haben.

Ansonsten die Performance ist nicht berauschend mehr - aber es "fühlt" sich flüssiger und direkter an - könnte auch Placebo sein

 

[Deinorius]

Wenn mein Desktop-PC fertig auf einem aktuellen Stand ist, könnte ich mir das sogar antun. Mal sehen.
Auf meinem Laptop macht das keinen Sinn und auf meinem Steam Deck will ich mir das nicht antun.

 

[aid0nex]

Bzgl ReiserFS:

Wer ~15 Minuten rum bekommen will, kann mag sich den Wikipedia Artikel zum Namensgeber Hans Reiser durchlesen, seinen Brief aus dem Hochsicherheitsgefängnis (Nov 2023) an die Linux Kernel Mailing List, oder einen Bericht zu jenem Brief.

Vielen Dank für die Links!! Ich wollte schon einen blöden Witz aka "jetzt haben die Kernel Maintainer den Code des Mörder ermordet" oder sowas schreiben, aber das hat sich dann dank deiner Links erübrigt, die viel interessanter sind und mir auch hochkommende Fragen, was Reiser denn persönlich dazu denken würde und ob er das überhaupt mitbekommt beantworten. Ein sehr spannender Zeitvertreib, auch wenn ich persönlich niemals dazu in der Lage wäre ein FS zu schreiben oder den Code eines FS zu verstehen.

 

[D.S.i.u.S.]

Kann es vielleicht sein, dass in letzter Zeit viele custom Kernel wie z.B. cachyOS oder zen Kernel kein FPS Zuwachs gegenüber 0815-Linux-Kernel in Spielen bringen? Es ist nur 1-2 FPS Unterschied. Nur bei 1% low gibt es größere Unterschiede. Mal sehen, wie es mit 6.13 sein wird. Wenn ich Zeit dafür habe, mache ich vielleicht einen Test mit 0815-Linux-Kernel, CachyOS und zen Kernel.
Unter NixOS nutze ich zurzeit noch CachyOS Kernel.
Ob ich weiterhin CachyOS Kernel verwenden soll? Ich werde es prüfen.

 

[Deinorius]

Die Unterschiede zwischen diversen kernel forks zeigen sich so oder weniger in fps, min.fps vielleicht eher. Wenn ein kernel z.B. auf kurze Latenzen optimiert wird, sieht man das nicht in Spielen.

 

[Krik]

Zumindest auf meinem Steam Deck fühlt sich CachyOS deutlich reaktionsfreudiger an. FPS gibt es, glaub ich, nicht wirklich mehr bzw. es liegt unter meiner Wahrnehmungsschwelle, aber das juckt mich nicht. Alleine, dass das System weniger träge reagiert, hat sich für mich gelohnt.

Nur eine Sache stört mich: Warum sind manche Pakete geblockt? Da fehlt mir einfach etwas Dokumentation über die Hintergründe.
Bspw. blockt /usr/share/libalpm/hooks/handheld-conflicts.hook das generelle Gaming-Paket cachyos-gaming-meta. Dem Dateinamen nach sorgt das für Konflikte, aber wo und warum? Und warum nur auf dem Handheld und nicht bei der Desktop-Edition?
Bei /usr/share/libalpm/hooks/blocked-packages.hook wird packagekit blockiert. Den Hook habe ich entfernt, da ich gelesen habe, dass dieses Packet nur im Zusammenhang mit Discover Probleme erzeugt. Ich verwende hier aber Discover nicht. Octopi ist für mich ausreichend.

 

[Krümel-Hamster]

Wenn ich so etwas schon lese läuft es mir eiskalt den Rücken runter, da bleibe ich schön bei Windows wie der riesige Rest eben auch.

Auch in Win musst Du die Option "Treiber" im BIOS setzten, zusätzlich die aktuellsten Chipsatztreiber installieren und die Windows-Game Bar, damit das mit der CCD-Zuweisung von Spielen richtig funktioniert.

 

[ptr1337]

Kann es vielleicht sein, dass in letzter Zeit viele custom Kernel wie z.B. cachyOS oder zen Kernel kein FPS Zuwachs gegenüber 0815-Linux-Kernel in Spielen bringen? Es ist nur 1-2 FPS Unterschied. Nur bei 1% low gibt es größere Unterschiede. Mal sehen, wie es mit 6.13 sein wird. Wenn ich Zeit dafür habe, mache ich vielleicht einen Test mit 0815-Linux-Kernel, CachyOS und zen Kernel.
Unter NixOS nutze ich zurzeit noch CachyOS Kernel.
Ob ich weiterhin CachyOS Kernel verwenden soll? Ich werde es prüfen.

CachyOS Kernel Maintainer hier:


Früher (2-5 Jahren) war der Kernel Scheduler kompletter Mist für den Desktop, weil es eben auch nicht für die Maintainer wichtig war. Die Server Performance musste stimmen und das wars.
Daher kamen recht viele Custom Kernels mit entweder:

• modifizierten scheduler values
• Custom Scheduler (paar beispiele: MuQSS, PDS, BMQ, BORE, Cacule , ...)

Diese haben generell die Desktop Erfahrung besser gemacht, und auch in Spielen.
Seitdem upstream zum "EEVDF" Scheduler gewechselt ist, ist der default kernel auch im Desktop relativ gut.

Bei CachyOS pullen wir derzeit oftmals Features, von den kommenden Kernel Versionen in die derzeitige kernel version.
Diese Patches werden erst getestet zusammen mit der Testing Community, und ebenfalls gebenchmarked. (Nicht nur Spiele FPS, generell lassen wir größere Testsuites durchlaufen).

Falls die patches eine Verbesserung darstellen - werden diese genutzt. Ebenfalls arbeiten wir damit zusammen mit den Entwicklern von diesen Patches, um Feedback und gegebenfalls Fehler zu reporten, dies passiert hauptsächlich zusammen mit AMD, da wir dort hin einen guten Kontakt haben.

Ansonsten gibt es noch einige Konfigurationänderungen, welche wir vornehmen, damit die Kernels besser auf dem Desktop sind - interactivity, latency und auch "heavy load responsives".
Wir nutzen auch einen anderen Scheduler (BORE), welche aber nur eine Verbesserung des Algorithmus von dem default Scheduler ist.

Dann dementsprechend, wie oben erwähnt wird noch AutoFDO/Propeller optimiert, aber dies gibt es nur in dem Repository von CachyOS, und nicht auf Nix. Die Nix maintainer müssten das Profilen übernehmen, aber dies ist eine lange Arbeit für jeden Kernel release (1-2 Stunden).

tldr:
Es gibt keine 10% mehr FPS in Spielen. Dies war früher wegen dem schlechten (Desktop) Scheduling so.
Man kann die 1% lows aber immer noch gut verbessern. Early Features, Konfiguration und auch fixes und Verbesserung sind der Hauptaspekt von den meisten Custom Kernels.

Ergänzung (21. Januar 2025)

Bspw. blockt /usr/share/libalpm/hooks/handheld-conflicts.hook das generelle Gaming-Paket cachyos-gaming-meta. Dem Dateinamen nach sorgt das für Konflikte, aber wo und warum? Und warum nur auf dem Handheld und nicht bei der Desktop-Edition?
Bei /usr/share/libalpm/hooks/blocked-packages.hook wird packagekit blockiert. Den Hook habe ich entfernt, da ich gelesen habe, dass dieses Packet nur im Zusammenhang mit Discover Probleme erzeugt. Ich verwende hier aber Discover nicht. Octopi ist für mich ausreichend.

Packagekit funktioniert leider nicht gut bei Archlinux. Die komplette Implentation damit man pacman + packagekit nutzen kann ist einfach nur schlecht und nicht richtig maintained.

Die meta ist blockiert, da dies schon mit dem "cachyos-handheld" paket kommt. Es gab ein Bug, wenn man ein Nativ compiled proton installiert hatte (nicht aktiv genutzt), das der Controller von dem Steam Deck nicht mehr funktioniert hatte - daher kam auch der meta block.

Dies ist mittlerweile seitens Steam gefixed und wir werden mit dem nächsten Release den Konflikt entfernen.

 

[Pummeluff]

Packagekit funktioniert leider nicht gut bei Archlinux.

Ich betreue auf Arbeit ein paar Fedora-Rechner. PackageKit hab ich da auch gleich rausoperiert.

Aber auf manchen VMs werkelte das Ding permanent bei 100%. Killt man den Prozess, wird der gleich von gnome-software wieder neugestartet. Die Ursache für den Amoklauf hab ich noch nicht rausgefunden. Mir hat das Ding bisher wesentlich mehr Ärger als Nutzen bereitet.