News Linux Kernel 6.12: Echtzeit-Kernel im Hauptzweig und eine Scheduler-Wahl

[Piktogramm]

Entsprechend wäre ein Echtzeit-Kernel für latenzarme Audioproduktion sogar eher hinderlich, weil die Berechnungen dann auch nie die genau definierte Laufzeit unterschreiten, selbst wenn sie eigentlich schneller fertig sein können. Ein Echtzeit-Kernel kann also Latenzen teils sogar erhöhen.

Mitnichten..
Das Konzept ist mein Betriebssystemen mit Multitaskingfähigkeit eher, dass es Deadlines gibt und das Betriebssystem versucht entsprechend priorisierte Aufgaben innerhalb dieser Deadline fertig zu haben. Es gibt keine Blockaden, wenn Aufgaben deutlich vor der Deadline fertig werden, dass wäre irgendwie absurd.

Siehe: https://wiki.linuxfoundation.org/realtime/documentation/technical_basics/start

 

[Ironbutt]

Cool, mal sehen ob wir dann bald eine FOSS CNC bekommen mit RT-Linux als Controller.

 

[scooter010]

meistens steht der Grund direkt da

Immer voll hilfreich, wenn der Bildschirm mit 10 Bildschirmseiten vollgepflastert ist. Mit den Werten aller Register, +/-10 Assemblerbefehle und das pro Kern.

Mag technisch korrekt sein. Aber wenn man nicht grade Entwickler auf Bughunt ist, dann ist das für mich nur ein Schulterzucken und neustarten. Dabei kann ich Assembler, C, weiß was die Standard Lib C ist, Core-utils sagen mir was, ich kenne den Unterschied von Compilern und Linkern, Compileroptionen, Caches Hierarchie, MMU, Paging, Unterschied Kernelspace vs. Userspace etc. pp. Trotzdem abseits des Bughunting einfach nutzlos.

 

[Bigeagle]

Das mit dem Scheduler verwundert mich ein wenig. Sollte nicht bisher auch schon die Priorität dafür da sein um manche Prozesse zu bevorzugen und andere in den Hintergrund zu verdrängen? Ich weiß dass das zum teil nicht unbedingt läuft wie erwartet, nur nicht so recht warum.

Weiß vielleicht jemand was der rustland scheduler anders macht? In den Code reinschauen kann ja jeder, aber bis ich daraus schlau werde dürfte etwas zeit ins land gehen :/
Sind die time slices kürzer als im default (CFS), macht der irgendwo eine anpassung der Priorität, oder unterscheiden die sich in der zuweisung der Gesamtzeit? Kein Scheduler sollte so viel eigenen Overhead haben dass das groß ins Gewicht fällt, das sollte es also nicht sein.
Auf den ersten Blick scheinen die slices beim CFS per default 0,75 bis 1,5 ms zu sein, bei rustland zwischen 0,5 und 5 ms. Klingt jetzt nicht nach etwas das den Unterschied von 30 auf 60 fps erklärt.

Der CFS lässt sich ja auch tunen, wäre das vergleichbar?

Aber die Wahl zu haben ist immer nett. Wenn man denn weiß wo die Unterschiede liegen um sich auch entscheiden zu können.

 

[pseudopseudonym]

Sollte nicht bisher auch schon die Priorität dafür da sein um manche Prozesse zu bevorzugen und andere in den Hintergrund zu verdrängen?

Sind die time slices kürzer als im default (CFS), macht der irgendwo eine anpassung der Priorität, oder unterscheiden die sich in der zuweisung der Gesamtzeit?

Ich hab mich mit den einzelnen Schedulern nicht beschäftigt, aber moderne Scheduler machen deutlich mehr, als Prozesse zu priorisieren und Timeslices zuzuteilen.

Ein einfaches Beispiel wäre das Verteilen von Threads auf CPU-Kerne, um Thermal-Throttling zu verhindern. Hast du zum Beispiel zwei ausgelastete Threads auf einem 8-Kerner, willst du die beiden Threads nicht auf benachbarte Kerne legen, weil die sich gegenseitig aufheizen. Auch willst du die Kerne mal durchwechseln, damit die sich abkühlen können. Gleichzeitig kostet jeder Kernwechsel (Kontextwechsel) wieder Rechenzeit, je nach Anwendung unterschiedlich viel. Diese Abwägungen zwischen Temperaturvorteilen und Kontextwechselnachteilen hängen von den Anwendungen ab. Das abzuwägen, wäre eine Aufgabe des Schedulers.

 

[Stuffz]

Gilt es schon als Clickbait, „Linux-Kernel“ in der Überschrift zu haben und im Aufmacher einen Windows-Bluescreen zu zeigen? 😁

Finde ich aber angemessen. 6.11.8 ist mir grade nach dem zweiten Aufwachen aus dem Standby abgeraucht (Hänger, nicht Neustart). Davor lief 6.10.irgrendwas monatelang stabil.

 

[scooter010]

@Stuffz das ist eine so kleine Stichprobe... Ebenso könnte Umgebungsstrahlung zufällig ein wichtiges Bit im Speicher gekippt haben, oder nicht?! Oder der Kernel hat tatsächlich einen Bug irgendwo, vielleicht in einem Treiber deiner Hardware. Darauf auf die ganze Kernel-Version zu pauschalisieren ist so, als würde man Linux grundsätzlich als instabil bezeichnen, weil Linux-Systeme sogar ohne Crowdstrike-Software abstürzen. ;-)

 

[Tanzmusikus]

6.11.8 ist mir grade nach dem zweiten Aufwachen aus dem Standby abgeraucht (Hänger, nicht Neustart).

Keine Probleme mit dem Standby (außer unter Windows -> AiO wacht nicht auf usw.) mit dem Zen-Kernel 6.11.8 von EndeavourOS bisher gehabt. Heute kam der 6.11.9 an.

 

[Dark Soul]

Sollte nicht bisher auch schon die Priorität dafür da sein um manche Prozesse zu bevorzugen und andere in den Hintergrund zu verdrängen?

Doch das geht In Windows im Task Manager in der Details Ansicht auf den Prozess rechtsklicken und die Priorität anpassen
In Linux benutzt man nice, also zB: 'nice -n 10 ./deinProgramm', - Skala von -19(höchste) bis 20 (niedrigste) Prio - wenn die Anwendung schon läuft einfach 'renice -n xx -p PPP', wobei xx die neue Prio ist, und PPP die PID des Prozesses.

Der Unterschied von RTOS zu einem "normalen / fairen" Scheduler ist, dass Prozesse verhungern können (starving) wenn ihre Prio tief ist. Ein fairer Scheduler versucht dies zu verhindern. Alle Prozesse sollen die CPU erhalten.

 

[Chismon]

Mit dem Kernel 6.12 soll sich das ändern und im Falle einer Kernel Panic ein QR-Code ausgegeben werden, welcher weiterführende Informationen bietet.

Das klingt durchaus gut, wenn die weiterführende Info dann auch ausreichend verständlich/umsetzbar für Einsteiger ist.

Schön zu sehen, dass sich Linux immer mehr zur Windows (Gaming) OS Alternative mausert, so dass Microsoft sich dann auch vorsehen muss, bei zukünftigen Windows OS den Nutzern nicht zuviel zu zu muten.

 

[mytosh]

Immer voll hilfreich, wenn der Bildschirm mit 10 Bildschirmseiten vollgepflastert ist. Mit den Werten aller Register, +/-10 Assemblerbefehle und das pro Kern.

Ja, ist es tatsächlich. Gut erkannt.
"driver irql not less or equal" ist quasi das genaue Gegenteil.

 

[Bigeagle]

@Dark Soul ich meinte dass das zumindest theoretisch ja das gleiche ergeben sollte, so naiv gedacht, wie der gezeigte scheduler wechsel in der demo
praktisch gibts hin und wieder prozesse die auch 'idle' (was ja offenbar nur very low prio ist, statt wirklich idle) noch normal oder gar hoch priorisierte prozesse heftig ausbremsen.
zumindest in windows hatte ich das einige male, unter linux bin ich nicht sicher. da fiel mir nur auf dass der unterschied zuweilen arg gering war. einen störenden prozess auf nice 19 zu stellen brachte manchmal kaum eine spürbare änderung. vermutlich war der scheduler 'zu fair' und ich hätte den umstellen müssen. so weit war ich da aber nicht :/

 

[Piktogramm]

Das klingt durchaus gut, wenn die weiterführende Info dann auch ausreichend verständlich/umsetzbar für Einsteiger ist.

Kernelpanics sind tendenziell immer etwas für Fortgeschrittene. Genauso, wenn man die Abhilfe dazu einem Anfänger beschreiben kann, hätte man auch gleich Gegenmaßnahmen programmieren können.

 

[Haldi]

Beim Smartphone, Smart TV oder Wi-Fi-Router wird der Endanwender doch eher selten den Kernel-Scheduler wechseln.

"Endanwender" huh....
Es gibt sehr viele Leute die auf Ihrem Handy ein Custom Kernel installiert haben und auch an den Scheduler rumpfuschen.
Gerade darum existieren ja Foren wie XDA und so.

Folglich kann man dafür auch eine Automatik bauen.
Das kann sehr wohl auch für deine Beispiele interessant sein, ganz besonders bei Smartphones.

Kann man auch jetzt bereits.
Wird seit über 10 Jahren im Smartphone bereich gemacht. Das wenn Display Off ist ein anderer Scheduler läuft oder zumindest andere Parameter. Mit Root kann man da auch selber konfigurieren.

Es bleibt spannend zu sehen, wie diese Features in der Praxis angenommen

Geplant war das Feature eigentlich mal für Debugging. Das man Scheduler einfacher wechseln kann.
Bin gespannt wann das bei Android ankommt und ob man es im userspace überhaupt nutzen kann oder nur mit root. Und ob man externe Scheduler importieren kann ohne den Kernel neu kompilieren zu müssen.

 

[AGB-Leser]

Cool, mal sehen ob wir dann bald eine FOSS CNC bekommen mit RT-Linux als Controller.

Gibt es doch schon, nennt sich LinuxCNC

 

[foofoobar]

gibt es für einen normal User vorteile eines echtzeit-kernels?

Wahrscheinlich hat der normale User keine passende CPU: https://en.wikipedia.org/wiki/System_Management_Mode

Ergänzung (19. November 2024)

praktisch gibts hin und wieder prozesse die auch 'idle' (was ja offenbar nur very low prio ist, statt wirklich idle) noch normal oder gar hoch priorisierte prozesse heftig ausbremsen.

Was ist der Unterschied zwischen "idle" und "wirklich idle"?

Ergänzung (19. November 2024)

Mag technisch korrekt sein. Aber wenn man nicht grade Entwickler auf Bughunt ist, dann ist das für mich nur ein Schulterzucken und neustarten. Dabei kann ich Assembler, C, weiß was die Standard Lib C ist, Core-utils sagen mir was, ich kenne den Unterschied von Compilern und Linkern, Compileroptionen, Caches Hierarchie, MMU, Paging, Unterschied Kernelspace vs. Userspace etc. pp. Trotzdem abseits des Bughunting einfach nutzlos.

Was schlägst du stattdessen abseits von Kdump vor?

Ergänzung (19. November 2024)

Kernelpanics sind tendenziell immer etwas für Fortgeschrittene. Genauso, wenn man die Abhilfe dazu einem Anfänger beschreiben kann, hätte man auch gleich Gegenmaßnahmen programmieren können.

Welche Gegenmaßnahmen hast du bisher commited?

Ergänzung (19. November 2024)

Ein einfaches Beispiel wäre das Verteilen von Threads auf CPU-Kerne, um Thermal-Throttling zu verhindern. Hast du zum Beispiel zwei ausgelastete Threads auf einem 8-Kerner, willst du die beiden Threads nicht auf benachbarte Kerne legen, weil die sich gegenseitig aufheizen. Auch willst du die Kerne mal durchwechseln, damit die sich abkühlen können.

Wo steht die Information über die geografische Lage der Cores?

 

[Sensei21]

Das stimmt so nicht, Scheduler haben auch auf das Temperaturverhalten und/oder den Stromverbrauch von CPUs große Auswirkungen, aber eben auch auf die Performance bestimmter Anwendungen.
Dementsprechend kann auch dieses Scheduler-Wechseln für den Endanwender große Vorteile bringen.

genau !

also wenn die CPU halb soviel Strom verbraucht - ist das im Akkubetrieb schon spürbar:

z.B. http://arighi.blogspot.com/2024/05/extend-your-battery-life-with.html?ref=dailydev

Ergänzung (19. November 2024)

Wie das mit dem Scheduler funktioniert währe interessant. Und zwar eher von der Anwender seite. 😅

Ergänzung (18. November 2024)

gibt es für einen normal User vorteile eines echtzeit-kernels?

Anwendungsbeispiel ?

scx_lavd laufen lassen

im Hintergrund ein Backup-Job via rsync (Datenbackup or System-Partition Backup)

und währenddessen Overwatch via proton ge mit niceness von -20 und wineserver mit niceness von -19 laufen lassen

die FPS sind zwar dann ungefähr die Hälfte (regulär 225 - während des Backups ~ 90-120 schwankend bis maximal ungefähr 180 - immer noch genug dass es flüssig wirkt und die Frametimes sind hoch genug), die Latenzen und das Verhalten im Spiel sind aber immer noch zuverlässig und gegeben, auch kein Paket-Drops im Internet, etc. - jedes Subsystem ist also nicht kompromittiert - also echtes Multitasking ohne Kompromisse

 

[gaelic]

Naja, irgendwie schon. Vielleicht ist sie für weniger versierte Anwender nicht verständlich genug, aber meistens steht der Grund direkt da oder ist aus den Logs entnehmbar und nicht nur Windows-like "unerwarteter Fehler". Der QR-Code ändert auch nichts daran. Dann bekommt man einfach so ein Bild:
Anhang anzeigen 1545047

Ich finde das gut, denn dann hat man das Log bzw den Trace als Text und kann dann eine Suche machen, bzw. Das Log im Bugtracker einpflegen, etc.

 

[ReactivateMe347]

Steckt hier hinter den QR Codes ebenso unspezifisches Bla Bla wie bei Microsoft?

 

[mibbio]

@ReactivateMe347 steht doch in #10, welche Informationen der QR-Code enthält. Ist einfach ein Auszug aus dem Log vom Kernel zum Zeitpunkt des Crashes.