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

[ElliotAlderson]

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

Mit "DRIVER_IRQL_NOT_LESS_OR_EQUAL" kann ein Laie aber was anfangen. Das kann ich Googlen und weiß dann, was es ungefähr ist. Mit ASM Codes und Speicherbereiche kann ich genau was anfangen? Nichts, solange ich keine Ahnung habe.

 

[Stuffz]

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.

Damit wollte ich eigentlich sagen, dass auch die Stable-Branches nicht unbedingt kugelsicher sind. Aber wir können uns auf LTS-Branches einigen, da scheint es tatsächlich noch genug Sorgfalt zu geben.

Und bei meinem Beispiel tippe ich eben auf so einen Schluddrigkeitsbug.

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.

Naja, 6.11.8 ist gar nicht soo alt und 6.11.9 kam nur FÜNF Tage später. Habe mir mal das Commit-Log angeschaut, und da sind schon ein paar Brüller dabei, kein Wunder dass die es eilig hatten. Der 6.11.9 läuft übrigens wieder soweit unauffällig. Aber heute kommt 6.12 drauf - neues Spiel, neues Glück.

 

[wechseler]

Du vergisst aber auch die Endanwender, die Linux auf Laptops, PCs oder eben dem Steamdeck betreiben

Fallen für mich aber nicht unter Endanwender.

Es gibt sehr viele Leute die auf Ihrem Handy ein Custom Kernel installiert haben und auch an den Scheduler rumpfuschen.

Das sind Entwickler und keine Endanwender.

 

[JackTheRippchen]

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.

Nein, es bedeutet, dass - im konkreten Beispiel - die Multiplikation immer nach maximal 10 ms abgeschlossen ist, unabhängig der Werte. Natürlich kann die Berechnung auch schneller abgeschlossen sein.

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.

Mit Verlaub, das ist Blödsinn.

 

[lolinternet]

Ich hoffe ich habe nichts überlesen aber kann das mal jemand erläutern?

Durch die neue Erweiterung Sched_ext entfällt diese Notwendigkeit, denn dieser ermöglicht das dynamische laden eines Schedulers und damit die Anpassung an laufenden Anforderungen.

Auch auf die Gefahr hin mich zu blamieren aber heißt das diese Scheduler werden nun über dkms unterstützt oder wie muss ich mir das vorstellen?

 

[pseudopseudonym]

Fallen für mich aber nicht unter Endanwender.

Soso, unter was dann? Gerade für Valve sicher eine spannende Frage.

Ergänzung (19. November 2024)

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

So tief kann ich mich an die entsprechenden Vorlesungsinhalte nicht mehr erinnern, zumal ich in dem Bereich auch nicht arbeite.
Vermutlich ergibt sich das aus der Nummerierung der Cores.

 

[wechseler]

Alt, aber passend:

 

[stefan92x]

Auch auf die Gefahr hin mich zu blamieren aber heißt das diese Scheduler werden nun über dkms unterstützt oder wie muss ich mir das vorstellen?

Das sind in eBPF geschriebene Sachen, die man dann zur Laufzeit in den Kernel laden kann. Hier ein Tutorial, das relativ verständlich sein sollte was die Prinzipien angeht (selbst wenn man nie mit eBPF gearbeitet hat): https://mostlynerdless.de/blog/2024/10/25/a-minimal-scheduler-with-ebpf-sched_ext-and-c/

Das ist eben auch das schöne hier - man muss keine statisch installierten Sachen haben (wie ein DKMS wäre), sondern man kann wirklich dynamisch Laden was man braucht.

 

[scooter010]

Was schlägst du stattdessen abseits von Kdump vor?

Eine Auswahloption bzgl. des Detailgrades der Panikmeldung. Da das Thema Panik im Kernel behandelt wird, kann es nur schwerlich von den Distributionen kommen.

Letztlich so, wie es der Kernel derzeit macht. Ich sollte als Nutzer, ggf. mittels Bootparameter, entscheiden können, ob ich den Dump sehen möchte oder ob ich eine vereinfachte Ausgabe (wie im Artikel erwähnt) sehen möchte, die anhand festgelegter Kriterien über die wahrscheinlichste Ursache bzw. den abstrahierten Auslöser der Panik informiert.
Unabhängig davon sollte der Dump, wenn noch möglich, auf das Dateisystem geschrieben werden.

Problematisch ist hier etwas Anderes:
Wer betreibt die Webseite hinter den Barcode-Links? Betrieb und Pflege der Inhalte kosten Geld. Es muss weiterhin sichergestellt werden, dass diese Webseite - auch in 10 Jahren noch - "politisch/technisch neutral" ist.

Ergänzung (19. November 2024)

sondern man kann wirklich dynamisch Laden was man braucht

Das geht ja schon Richtung Live-Patching vom Kernel... Für Desktopuser nicht ganz so wichtig (außer die Fraktoin, die hunderte Fenster offen hat und die Büchse nie neustarten möchte), aber für Serverbetreiber sicherlich ganz nett.

 

[stefan92x]

Wer betreibt die Webseite hinter den Barcode-Links?

Niemand, denn da ist gar kein Link hinterlegt. In #10 siehst du ja ein Beispiel, da ist im QR-Code einfach nur das Log codiert, das führt zu keiner Webseite.

Ergänzung (19. November 2024)

Das geht ja schon Richtung Live-Patching vom Kernel... Für Desktopuser nicht ganz so wichtig (außer die Fraktoin, die hunderte Fenster offen hat und die Büchse nie neustarten möchte), aber für Serverbetreiber sicherlich ganz nett.

Also generell hast du damit recht. Soweit ich das verfolgt habe, ist das auch einfach ein Feature, auf das Kernel-Entwickler selbst ganz scharf sind, weil es das Entwickeln von Schedulern viel einfacher macht - zur Laufzeit neuen Code laden spart einfach enorm viel Zeit, und mit modernen CPUs mit x Kernen und wildesten heterogenen Architekturen ist das Entwickeln von Schedulern auch einfach nochmal deutlich aufwendiger geworden.

Trotzdem ist es aber gerade für Desktopuser unter Umständen vorstellbar, dass das interessant ist. Ich bin mal gespannt, ob es so kommt, dass demnächst "Spiele-Scheduler" verfügbar werden, nach dem Prinzip "Lade für Spiel X diesen Scheduler, schon hast du 10fps mehr". Keine Ahnung, ob das passieren wird, aber die Möglichkeit für sowas besteht halt damit.

 

[pseudopseudonym]

Alt, aber passend:

Anhang anzeigen 1545280

Achso, du bist nur zum Trollen im Thread. Schade...

 

[KJQm8v]

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

Und der Code enthält folgenden Text:

In Debian Etch die letzte Panik Attacke gehabt. Sieht schick aus.

 

[JustAnotherTux]

Fallen für mich aber nicht unter Endanwender.

Sondern ?

Alle privat PCs & Notebooks bei mir im Haus verwenden Linux.



Zur news:
Das mit dem Bluescreen ist eine gute Sache.

Ergänzung (19. November 2024)

Alt, aber passend:

Anhang anzeigen 1545280

Finde ich nicht passend, in den Linux Kernel fließt eben Arbeit von verschiedenen Interessengruppen ein.

 

[Piktogramm]

Welche Gegenmaßnahmen hast du bisher commited?

Keine Ahnung wie du zu der Frage kommst, ich bin aber sowieso kein produktiver Programmierer.

Der springende Punkt war aber sowieso dieser: Betriebssystemkernel werden so entwickelt, dass Fehler abgefangen und nicht zum KernelPanic führen. Die Ausnahme sind eben jene Panics und wären spezifische Ausnahmen bewusst und kompensierbar, wären sie in die Fehlerbehandlung eingeflossen.

 

[mytosh]

Mit "DRIVER_IRQL_NOT_LESS_OR_EQUAL" kann ein Laie aber was anfangen.

Ja, is klar. Dann schreib doch bitte mal eben, was es so ist. Vielleicht fällt dir dabei etwas auf.

 

[Sensei21]

Ich hoffe ich habe nichts überlesen aber kann das mal jemand erläutern?

Auch auf die Gefahr hin mich zu blamieren aber heißt das diese Scheduler werden nun über dkms unterstützt oder wie muss ich mir das vorstellen?

das läuft nicht also Kernel-Modul sondern als bpf "Programm":

https://de.wikipedia.org/wiki/Berkeley_Packet_Filter

https://blogs.igalia.com/changwoo/sched-ext-a-bpf-extensible-scheduler-class-part-1/

Ich hab mal bei AUR vorbeigeschaut - zumindest dort gibt es von den CachyOS Entwicklern die scx-Programme zu kompilieren und installieren

die fertigen Programme werden dann via

sudo ./scx_lavd

z.B. geladen

https://aur.archlinux.org/packages/scx-scheds
https://aur.archlinux.org/packages/scx-scheds-git

Ergänzung (20. November 2024)

Niemand, denn da ist gar kein Link hinterlegt. In #10 siehst du ja ein Beispiel, da ist im QR-Code einfach nur das Log codiert, das führt zu keiner Webseite.

Ergänzung (19. November 2024)

Also generell hast du damit recht. Soweit ich das verfolgt habe, ist das auch einfach ein Feature, auf das Kernel-Entwickler selbst ganz scharf sind, weil es das Entwickeln von Schedulern viel einfacher macht - zur Laufzeit neuen Code laden spart einfach enorm viel Zeit, und mit modernen CPUs mit x Kernen und wildesten heterogenen Architekturen ist das Entwickeln von Schedulern auch einfach nochmal deutlich aufwendiger geworden.

Trotzdem ist es aber gerade für Desktopuser unter Umständen vorstellbar, dass das interessant ist. Ich bin mal gespannt, ob es so kommt, dass demnächst "Spiele-Scheduler" verfügbar werden, nach dem Prinzip "Lade für Spiel X diesen Scheduler, schon hast du 10fps mehr". Keine Ahnung, ob das passieren wird, aber die Möglichkeit für sowas besteht halt damit.

scx_lavd ist ein heißer Kandidat für Spiele-Scheduler - die anderen laufen nicht so toll mit z.B. Overwatch

 

[ReactivateMe347]

Ist einfach ein Auszug aus dem Log vom Kernel zum Zeitpunkt des Crashes.

Na, dann dürfte das ja für jeden verständlich sein

Aber es ist zumindest besser als wirre Fehlercodes mit unspezifischen, schlecht maschinenübersetzen Ursachenlisten.

 

[Bigeagle]

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

'idle' prio ist wenig rechenzeit, aber ein minimaler anteil damit der prozess nicht 'verhungert'
wirklich idle prio wäre ohne den minimalanteil, so dass der prozess eben wirklich nur läuft wenn die cpu gerade nichts anderes zu tun hat.

praktisch: läuft z.b. ein spiel, oder interaktives programm das höchst empfindlich auf konkurrenz auf der cpu ist sollte ein echter idle task keinen effekt haben, während ein 'idle' task ggf. für ruckeln sorgt. hatte den spaß als ich vor jahren bei einem freund boinc im hintergrund laufen lassen wollte, doch photoshop fing an hart zu ruckeln beim zeichnen und das obwohl es praktisch nur einen von sechs kernen nutze. auch manuelle zuweisung machten keinen unterschied, selbst ein einzelner kern mit einem rechenintensiven task war spür- und sichtbar störend. keine ahnung was da schief läuft.
unter linux hab ich mir vor gut 10 jahren in der ausbildung auch mal den pc weitgehend lahmgelegt beim test eines benchmarks mit niedriger priorität. wollte gucken welchen einfluss firefox auf die leistung hat oder so. nur war surfen plötzlich schnarchlahm.

fazit war also: 'idle' ist nicht idle und nur weil eine anwendung nur einen kern nutzt heißt das nicht dass man die anderen nutzen darf ohne dass die anwendung möglicherweise schmollt weil sie nicht den ganzen spielplatz für sich allein hat.

 

[foofoobar]

'idle' prio ist wenig rechenzeit, aber ein minimaler anteil damit der prozess nicht 'verhungert'
wirklich idle prio wäre ohne den minimalanteil, so dass der prozess eben wirklich nur läuft wenn die cpu gerade nichts anderes zu tun hat.

Wäre mir neu das es sowas unter unix/linux gibt.

praktisch: läuft z.b. ein spiel, oder interaktives programm das höchst empfindlich auf konkurrenz auf der cpu ist sollte ein echter idle task keinen effekt haben, während ein 'idle' task ggf. für ruckeln sorgt. hatte den spaß als ich vor jahren bei einem freund boinc im hintergrund laufen lassen wollte, doch photoshop fing an hart zu ruckeln beim zeichnen und das obwohl es praktisch nur einen von sechs kernen nutze. auch manuelle zuweisung machten keinen unterschied, selbst ein einzelner kern mit einem rechenintensiven task war spür- und sichtbar störend. keine ahnung was da schief läuft.
unter linux hab ich mir vor gut 10 jahren in der ausbildung auch mal den pc weitgehend lahmgelegt beim test eines benchmarks mit niedriger priorität. wollte gucken welchen einfluss firefox auf die leistung hat oder so. nur war surfen plötzlich schnarchlahm.

fazit war also: 'idle' ist nicht idle und nur weil eine anwendung nur einen kern nutzt heißt das nicht dass man die anderen nutzen darf ohne dass die anwendung möglicherweise schmollt weil sie nicht den ganzen spielplatz für sich allein hat.

Klingt alles sehr diffus und nach anekdotischer Evidenz.

 

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

@Sensei21
Was macht scx_lavd hinsichtlich der Spiele anders als BORE?