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 :/