estamos kilka dni po wydaniu stabilnej wersji Linuksa 6.10, wersję, która będzie zawierała szereg całkiem interesujących zmian, a także świetne ulepszenia w zakresie obsługi urządzeń, funkcji i nie tylko.
W odpowiednim czasie będziemy mówić o tym wydaniu, ponieważ powodem tego artykułu jest nawiązanie do kolejnej oczekiwanej wersji Linuksa, czyli „Linux 6.11”, w której ogłoszono pewne zmiany, o których wspominam wystarczająco dużo czasu, chętnie omówię je w innym poście.
OK, teraz przejdźmy do sedna artykułu, który jest w nawiązanie do oświadczenia Linusa Torvaldsa niektórzy mówią o chęci włączenia jądra Linuksa 6.11 poprawki implementujące ten mechanizm „sched_ext” (SCX).
Ten mechanizmlub ma na celu użycie eBPF do tworzenia harmonogramów procesora w jądrze Linuksa. Oto podsumowanie tego, jak to będzie działać:
- Programiści eBPF i CPU: Dzięki zastosowaniu eBPF harmonogramy procesora mogą być dynamicznie ładowane i wykonywane w jądrze Linuksa. Kompilacja Just-In-Time (JIT) tłumaczy kod bajtowy eBPF na instrukcje maszynowe w celu wykonania.
- Klasa SCHED_EXT: Jest to nowa klasa programistyczna, której priorytet wywołań jądra znajduje się wśród klas SCHED_IDLE i SCHED_NORMAL. Sterowniki BPF powiązane z SCHED_EXT może obsługiwać zadania o niższym priorytecie niż wykonywanie w czasie rzeczywistym, bez wpływu na zadania już dołączone do normalnego harmonogramu SCHED_NORMALNY.
- Działanie: Sterowniki BPF analizują kolejki zadań oczekujących na wykonanie na procesorze i wybierają, które zadanie przypisać po zwolnieniu rdzenia procesora. Jeśli nie ma aktywnych sterowników BPF SCHED_EXT, zadania są obsługiwane za pomocą harmonogramu SCHED_NORMALNY.
- Korzyści: Mechanizm sched_ext ułatwia eksperymentowanie z różnymi technikami i strategiami programowania w sposób dynamiczny. Pozwala to na szybkie tworzenie funkcjonalnych prototypów programistów i zastępowanie ich na bieżąco w środowiskach produkcyjnych. Można na przykład dostosować go do specyficznych cech aplikacji i zmienić strategię planowania w oparciu o stan systemu i inne czynniki.
Warto zaznaczyć, że „sched_ext” został pierwotnie zaproponowany do rozważenia przez twórców jądra w 2022 roku, po czym wydano sześć wersji poprawek. Pomimo braku obsługi w głównym jądrze, Kilka dystrybucji, takich jak Ubuntu, Arch Linux, Fedora i NixOS, oferuje instalację „sched_ext” poprzez dodatkowe pakiety. Firma Canonical rozważa włączenie komponentów «sched_ext» w Ubuntu 24.10, a Valve pracuje nad jego integracją z Steam Deck. W Meta programista oparty na «sched_ext» jest już stosowany w infrastrukturze produkcyjnej.
Ponadto wspomina się, że obecnie około kilkunastu programistów opiera się na „sched_ext”, każdy z logiką planowania zadań zdefiniowaną w przestrzeni użytkownika i ładowaną do jądra za pomocą programów BPF.
- scx_layered: Hybrydowy harmonogram, który dzieli zadania na warstwy, z których każda ma własną strategię planowania. Umożliwia przypisanie określonych zadań do konkretnych warstw z gwarantowanymi zasobami procesora lub zwiększenie priorytetu poszczególnych aplikacji. Opracowany przez Meta, jego logika przestrzeni użytkownika jest napisana w Rust.
- scx_rustland: Zoptymalizowany pod kątem priorytetowego traktowania zadań interaktywnych zamiast zadań intensywnie obciążających procesor. Na przykład poprawia FPS w grze Terraria podczas jednoczesnej kompilacji jądra w porównaniu ze standardowym harmonogramem EEVDF. Opracowany przez pracownika Canonical, z logiką w Rust.
- scx_lavd: Implementuje algorytm LAVD (Latency-critical Aware Virtual Deadline), redukując opóźnienia w grach komputerowych i zadaniach interaktywnych, biorąc pod uwagę znaczenie zmniejszania opóźnień i postępu procesu. Opracowany przez Igalię i Valve, z logiką w Rust.
- scx_rusty, scx_rlfifo, scx_mitosis: Harmonogramy równoważące grupy zadań w oparciu o obciążenie, implementujące prosty harmonogram FIFO i wiążące grupy zadań z rdzeniami procesora. Wszystko z komponentami Rust.
- scx_central, scx_flatcg, scx_nest, scx_pair, scx_qmap, scx_simple, scx_userland: Przykłady programistów z komponentami C, demonstrujące różne możliwości „sched_ext”.
Na koniec warto dodać, że Google eksperymentuje z wykorzystaniem własnego frameworka ghOSt do wpływania na decyzje dotyczące harmonogramu zadań za pomocą programów BPF i rozpoczął migrację ghOSt do sched_ext. Dodatkowo Google pracuje nad portem „sched_ext” dla ChromeOS.
źródło: https://lkml.org