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

[Kaito Kariheddo]

Nach langer Zeit paralleler Entwicklung, wandert der Echtzeit-Kernel in den Hauptzweig von Linux. Obendrein erhält Linux eine flexiblere Scheduler-Wahl und zahlreiche neue Features. Kernel 6.12 führt unter anderem auch noch QR-Codes bei Abstürzen und Arbeiten rund um Hardware ein.

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

 

[Northstar2710]

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

Ergänzung (Heute um 17:27)

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

 

[Termy]

Und zwar eher von der Anwender seite.

Ich gehe mal davon aus, dass da eher früher als später entsprechende Patchers im feral gamemode landen werden

gibt es für einen normal User vorteile eine live kernels?

Kurz: nein.
Im privaten Umfeld kenne ich ausser Musikproduktion eigentlich keinen Anwendungsfall dafür.

 

[Donnerkind]

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

gibt es für einen normal User vorteile eine live kernels?

Ein konkretes Beispiel wird im Artikel direkt demonstriert. Du hast eine bessere Ressourcenverteilung im Fall einer besonders starken Systemauslastung, sodass andere Anwendungen weiterhin schnell bleiben und nicht abgedrängt werden.

Nach langer Zeit paralleler Entwicklung, wandert der

„Nach langer Zeit paralleler Entwicklung“ ist kein Nebensatz, weshalb das Komma danach eigentlich nur von der gefühlten Sorte ist. duckundwegrenn

 

[Termy]

Ein konkretes Beispiel wird im Artikel direkt demonstriert. Du hast eine bessere Ressourcenverteilung im Fall einer besonders starken Systemauslastung, sodass andere Anwendungen weiterhin schnell bleiben und nicht abgedrängt werden.

Nein, das hat nichts mit dem RT Kernel zu tun

 

[GokuSS4]

wieso der Bluescreen als Thumbnail

 

[Suspektan]

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

in der Theorie bei Emulation älterer Systeme
In der Realität wird es wahrscheinlich an der Leistung scheitern, da zu viele Pozesse zeitgleich Priorität einfordern und sich der Lag im Ergebnis damit signifikant erhöht.
Ich habe mehrfach Latenzmessungen durchgeführt und es war nie die Emulation selbst, welche Lag addierte, sondern das OS selbst. ( und diese Latenz kann auch das Runahead feature von retroarch nicht beseitigen)

 

[mibbio]

Im privaten Umfeld kenne ich ausser Musikproduktion eigentlich keinen Anwendungsfall dafür.

Dafür braucht man ein Audio-Subsystem mit möglichst geringen Latenzen in den Verarbeitungsschritten, was aber erstmal nicht viel mit eine Realtime-Kernel zu tun hat. Wobei "Echtzeit" in dem Zusammenhang auch eher irreführend ist, denn das bedeutet schlicht, dass bestimmte Berechnungen garantiert immer gleich lange dauern - also eine Matrixmultiplikation immer exakt 10 ms dauert, egal welche Werte die Matrix enthält.

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.

 

[wechseler]

Scheduler-Geschichten interessieren hauptsächlich irgendwelche Cloud-Anbieter, die Hardware-Leistung möglichst definiert auf virtuelle Systeme aufteilen wollen, welche dann weitervermietet werden.

Für den Endanwender hat das Ganze null Relevanz, für den wurde Linux auch nicht entwickelt.

 

[Amaoto]

Leider bietet das System bislang keinerlei hilfreiche Informationen für die Absturzursache.

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:


Und der Code enthält folgenden Text:

Spoiler

[    3.319019] RPC: Registered tcp-with-tls transport module.
[    3.319019] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    3.606789] NET: Registered PF_QIPCRTR protocol family
[    6.181205] rfkill: input handler disabled
[    7.416796] input: spice vdagent tablet as /devices/virtual/input/input7
[   61.830264] sysrq: Trigger a crash
[   61.830271] Kernel panic - not syncing: sysrq triggered crash
[   61.830276] CPU: 6 PID: 2354 Comm: bash Not tainted 6.10.0-rc1+ #88
[   61.830278] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20240524-2.fc39 05/24/2024
[   61.830280] Call Trace:
[   61.830282]  <TASK>
[   61.830285]  dump_stack_lvl+0x2d/0x90
[   61.830294]  panic+0x118/0x300
[   61.830297]  sysrq_handle_crash+0x1a/0x20
[   61.830299]  __handle_sysrq+0x130/0x140
[   61.830302]  write_sysrq_trigger+0x4c/0x80
[   61.830304]  proc_reg_write+0x68/0xb0
[   61.830306]  vfs_write+0x111/0x3e0
[   61.830308]  ? do_syscall_64+0x9a/0x170
[   61.830310]  ksys_write+0x72/0xe0
[   61.830312]  do_syscall_64+0x8e/0x170
[   61.830314]  ? do_syscall_64+0x9a/0x170
[   61.830315]  ? filp_close+0x5c/0x80
[   61.830317]  ? do_dup2+0xae/0x110
[   61.830319]  ? syscall_exit_to_user_mode+0xb0/0xd0
[   61.830321]  ? do_syscall_64+0x9a/0x170
[   61.830323]  ? __se_sys_fcntl+0x64/0xb0
[   61.830324]  ? syscall_exit_to_user_mode+0xb0/0xd0
[   61.830326]  ? do_syscall_64+0x9a/0x170
[   61.830328]  ? ptep_set_access_flags+0x27/0x40
[   61.830330]  ? _raw_spin_unlock+0xe/0x30
[   61.830332]  ? do_wp_page+0x7f4/0x1100
[   61.830334]  ? __se_sys_fcntl+0x64/0xb0
[   61.830335]  ? syscall_exit_to_user_mode+0xb0/0xd0
[   61.830337]  ? __count_memcg_events+0x6e/0x100
[   61.830338]  ? handle_mm_fault+0xa18/0x13e0
[   61.830340]  ? kmem_cache_free+0x2d/0x2e0
[   61.830344]  ? do_user_addr_fault+0x212/0x750
[   61.830346]  ? clear_bhb_loop+0x25/0x80
[   61.830348]  ? clear_bhb_loop+0x25/0x80
[   61.830350]  ? clear_bhb_loop+0x25/0x80
[   61.830352]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   61.830356] RIP: 0033:0x7f11316cb834
[   61.830360] Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d 15 f8 0d 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
[   61.830361] RSP: 002b:00007ffc1b0593c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[   61.830364] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f11316cb834
[   61.830365] RDX: 0000000000000002 RSI: 00005566aa3202e0 RDI: 0000000000000001
[   61.830366] RBP: 00007ffc1b0593f0 R08: 0000000000000073 R09: 00000000ffffffff
[   61.830367] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000002
[   61.830368] R13: 00005566aa3202e0 R14: 00007f11317a45c0 R15: 00007f11317a1f00
[   61.830371]  </TASK>
[   61.830543] Kernel Offset: 0x3a000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

 

[andi_sco]

Bluescreen

Wegen dem QR-Code?

 

[garfield121]

... also eine Matrixmultiplikation immer exakt 10 ms dauert, egal welche Werte die Matrix enthält.

Ich denke, es bedeutet, es darf maximal 10 ms dauern, keinesfalls länger.

 

[pseudopseudonym]

Für den Endanwender hat das Ganze null Relevanz

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.

 

[Redundanz]

garantierte / "abgesteckte" ausführungsdauer ist wieder was anderes als latenzen, wo letztere in der tat für audioapps relevant sein können.

 

[konkretor]

Der 6.12 soll wohl auch LTS Kernel werden. Der gefällt mir

 

[wechseler]

Dementsprechend kann auch dieses Scheduler-Wechseln für den Endanwender große Vorteile bringen.

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

 

[AGB-Leser]

Dafür braucht man ein Audio-Subsystem mit möglichst geringen Latenzen in den Verarbeitungsschritten, was aber erstmal nicht viel mit eine Realtime-Kernel zu tun hat. Wobei "Echtzeit" in dem Zusammenhang auch eher irreführend ist, denn das bedeutet schlicht, dass bestimmte Berechnungen garantiert immer gleich lange dauern - also eine Matrixmultiplikation immer exakt 10 ms dauert, egal welche Werte die Matrix enthält.

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.

Stimmt so nicht ganz.

Das bedeutet, dass Ereignisse zu einer bestimmten Zeit erwartbar sind. Egal ob 10ms oder 1000ms

 

[ComputerJunge]

also eine Matrixmultiplikation immer exakt 10 ms

Hätte bestimmt auch für irgendwen praktischen Nutzen, wenn diese Kernel-SLAs auf "höchstens" lauten würden. ^^

Aber der Anforderungskontext hier dürfte in großer Mehrheit zugesicherte Vorhersagbarkeit für Reaktions-/Ausführungszeiten sein.
Diese wiederum kann jeder mies programmierte Audiofilter umgehend zunichte machen. 😁

 

[pseudopseudonym]

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

Wer sagt, dass der Endanwender das selbst macht? Selbst einen anderen Scheduler einzustellen, ging vorher schon (mit etwas Aufwand). Das Besondere hier ist, dass das zur Laufzeit geht. Folglich kann man dafür auch eine Automatik bauen.
Das kann sehr wohl auch für deine Beispiele interessant sein, ganz besonders bei Smartphones.

Du vergisst aber auch die Endanwender, die Linux auf Laptops, PCs oder eben dem Steamdeck betreiben. Für meinen Linux-Laptop kann das sehr interessant werden, wenn diese dynamischen Wechsel automatisch statfinden.

 

[Mxhp361]

Besonders interessant ist auch die Wahlfreiheit beim Scheduler, die es Nutzern erlaubt, ihre Systeme noch besser an spezifische Anforderungen anzupassen. Gerade im Hinblick auf High-Performance-Computing oder ressourcenintensive Workloads könnte das ein entscheidender Vorteil sein.

Es bleibt spannend zu sehen, wie diese Features in der Praxis angenommen werden und ob sie auch in den gängigen Distributionen standardmäßig Einzug halten. Ein weiterer Beweis dafür, wie flexibel und zukunftsorientiert die Linux-Entwicklung bleibt!