Red Hat chce zadbać o przydział zasobów dla głodzonych wątków
Portal Phoronix zwraca uwagę na projekt nowego demona opracowywanego przez firmę Red Hat i wkrótce gotowego do włączenia do Fedory. Jest nim stalld, wykrywacz ugrzęzłych (stalled) wątków. Ma on odpowiadać za zapewnienie zasobów umożliwiających finalizację pracy wątku i złączenie (join) z programem, celem kontynuacji przepływu. Choć intuicja podpowiada co innego (w jaki sposób kolejne narzędzie ma pomóc w rozwiązaniu braku zasobów?), demon stalld jest prosty i całkiem sensowny.
Sytuacja, w której system nie potrafi zapewnić zasobów pozwalających na ukończenie wątku nie zawsze wynika ze stuprocentowego obciążenia procesora/węzła pracą. Czasami jest to problem wynikający z niuansów działania systemowego planisty (scheduler). Pewne rzeczy trudno bowiem optymalnie zaplanować: programy mogą przełączać się między rdzeniami procesora i korzystać z różnych rdzeni celem wykonywania swojej pracy, ale wątki nie mają takiej wolności. Gdy wątek rozpocznie obliczenia na jakimś rdzeniu, nie da się go tak po prostu przenieść na inny (podobnie jak nie da się w pełni swobodnie gospodarować jego pamięcią).
Głodzone wątki
Można więc napotkać na sytuację, w której na tym samym rdzeniu zachodzi jakaś priorytetowa praca, przez którą pozostałe wątki nie mogą nawet wystartować. Taką sytuację nazywa się głodzeniem wątku. Kombinacja odpowiednio niekorzystnych okoliczności może sprawić, że wysoki priorytet stanie się priorytetem całkowitym: żadne inne zadanie nie może wystartować, choć jest już przygotowane i zaplanowane.
Stalld ma wykrywać takie sytuacje i wymuszać alokację ułamka czasu procesora tak, aby wątek mógł rozpocząć pracę. Takie zachowanie podważa "autorytet" systemowego planisty, nie zmieniając jednocześnie priorytetów (nice) procesów. Linuksowy planista nie jest wystarczająco elastyczny, by rozwiązać ten problem bez poważnego przeprojektowania, stąd też może zachodzić potrzeba innego rozładowania rosnącej kolejki zadań.
Zaawansowana kontrola zasobów
Stalld, aby pracować wydajnie, musi być przywiązany do rdzenia nieobarczonego pracą. Zatem poprawne jego wdrożenie wymaga świadomego zarządzania zasobami i zaawansowanej alokacji zasobów. W wielu takich czynnościach może pomagać systemd i jego mechanizm slices. Być może jednak stalld nie każdemu będzie potrzebny. Jeżeli specyfika zastosowania maszyny nie prowadzi do zakleszceń będących efektem głodzenia CPU, stalld się nie przyda.
Wreszcie, nie zawsze problemy z zagłodzeniem wątków brakiem CPU wynikają z łakomych zadań o wysokim priorytecie. O czas procesora mogą nie móc "doprosić się" na przykład maszyny wdrożone na niezoptymalizowanym hipernadzorcy. Osiem maszyn na ośmiordzeniowym serwerze wirtualizacji, w przypadku wyższego obciążenia może często nie otrzymywać czasu potrzebnego na niektóre zadania, co doprowadzi do zakleszczeń.
Optymalizowanie dostępności (availability, nie accessibility) wykracza dziś, jak widać, daleko poza klasycznego planistę opisywanego w książkach o projektowaniu systemów operacyjnych. W sytuacjach, gdy automatyczny load-balancing zawodzi, z pomocą przychodzą właśnie takie cudaczne pomysły, jak stalld. Można się z nim zapoznać na repozytorium Git projektu kernel.org. To ciekawa odmiana po dziesiątkach nowości rozwijanych pod egidą freedesktop.
