mibbio schrieb:
Aber ist dieses Feature mit dem Wechsel des Schedulers nicht gerade auch dafür gedacht, damit der Nutzer entscheiden kann, dass er gerade eine Situation hat, bei der ein anderer Scheduler die Arbeit anders verteilt?
Ich habe die Dokumentation nicht gelesen!
Aber überfliegen wir es mal:
sched_ext is a Linux kernel feature which enables implementing and dynamically loading safe kernel thread schedulers in BPF…
Threads? Nicht generell Prozesse.
Implementing application-specific schedulers and improving CFS are not conflicting goals. Scheduling features explored with sched_ext which yield beneficial results, and which are sufficiently generalizable, can and should be integrated into CFS. However, CFS is fundamentally designed to be a general purpose scheduler, and thus is not conducive to being extended with some highly targeted application or hardware specific changes.
One of our main goals was to lower the barrier to entry for experimenting with the scheduler. sched_ext provides ergonomic callbacks and helpers to ease common operations such as managing idle CPUs, scheduling tasks on arbitrary CPUs, handling preemptions from other scheduling classes, and more. While sched_ext does require some ramp-up, the complexity is self-contained, and the learning curve gradual. Developers can ramp up by first implementing simple policies such as global weighted vtime scheduling in only tens of lines of code, and then continue to learn the APIs and building blocks available with sched_ext as they build more featureful and complex schedulers.
Das Ding ist für Anwendungsentwickler und zum Experimentieren. Es soll wohl eben nicht den CFS ersetzen. Sondern dynamisch Änderungen am Thread-Scheduling für einen Prozess ermöglichen. Der CFS-Scheduler soll sich wohl wie gehabt um das System kümmern. Wobei der CFS schon von weiterer Entwicklung profitieren kann.
https://github.com/sched-ext/scx/blob/main/OVERVIEW.md
Vereinfacht:
Prozesse sind laufende Anwendungen, können neue Prozesse forken (mit eigenem Speicher) erstellen oder „nur“ neue Threads (kein eigener Speicher) nutzen.
Wer seinem Spiel Ressourcen zuweisen möchte, ist mit Control-Groups (CGroups) bedient. Das ist für Anwender. Darum kümmert sich aber schon Flatpak bzw. Docker. Oder man nimmt die alten Werkzeuge, also „nice“. Endanwender rate ich mal lässig, nicht zu tun ist richtig. Lasst es
Ausflug:
Ich nutze Control-Groups gerne mal um Webbrowser auf 1024 MB Hauptspeicher zu limitieren[1], der Kernel nimmt es nicht ganz so genau (aus Gründen) und ein paar Kilobyte später gibt es eine amtliche Hinrichtung mit Ansage. Wohldefiniertes Verhalten. Kein OOM-Killer, kein Risiko für das System oder kritische Anwendungen.
Oder man gibt Prozessorzeit vor, die Auslastung, die I/O zur Disk oder die I/O zum Netzwerk.
Für Endanwender ist das nichts. Darum kümmern sich hoffentlich zunehmend Entwickler und Paketmaintainer. Bei Systemd und Flatpak sehen wir das schon. In einer idealeren Welt wissen wir wie viel Ressourcen wir haben, was die Anwendung nutze sollte und machen dann spezifische Vorgaben.
PS: Control-Groups sind immer noch viel zu wenig genutzt. Damit kann man wohldefiniertes Verhalten vorgeben. So viel Speicher das Multi-User-Target, so viel GDM und GNOME, genau so viel für die Anwendung X, Y, Z. Das ist angenehm für den Anwender oder rettet Menschenleben bei kritischen Systemen. Der OOM-Killer ist nur die letzte Notwehr des Kernel, mit zahlreichen unbeteiligten Opfern.
[1] Ich wusste, dass da ein Speicherleck ist.
