Linux miał 256 wątków i nie umiał ich wykorzystać. AI znalazła problem

Kompilowanie jądra Linuksa od lat jest jednym z dobrych sposobów na sprawdzenie możliwości sprzętu. Teraz ten proces może stać się wyraźnie szybszy dzięki poprawkom przygotowanym przez dewelopera Lorenzo Stoakesa. Co ciekawe, podczas poszukiwania wąskich gardeł pomógł mu model językowy AI.

Efekt jest konkretny. Serwer wyposażony w dwa procesory AMD Epyc 9575F potrzebował około 15–17 sekund na zbudowanie standardowej wersji jądra x86-64. Wcześniej ten sam test zajmował około 22 sekund. Deweloper ARM, Lorenzo Stoakes, zidentyfikował wąskie gardła w systemie kompilacji, wykorzystując model sztucznej inteligencji.

Sztuczna inteligencja znalazła wąskie gardła

22 poprawki Kbuild (czyli infrastruktury odpowiadającej między innymi za proces budowania jądra)  autorstwa Lorenzo Stoakesa paralelizują kroki w procesie kompilacji jądra Linuksa, które wcześniej wykorzystywały tylko jeden rdzeń procesora. Oprócz samego Kbuild, poprawki te wpływają na kallsyms, modpost, objtool i infrastrukturę kompilacji Rust. Według Stoakesa,  model językowy zidentyfikował te wąskie gardła i jednocześnie zaproponował rozwiązania. Każdy z commitów został oznaczony informacją o wykorzystaniu pomocy AI. Co ciekawe, podczas kolejnych prac sam system sztucznej inteligencji używany do przeglądania zmian wskazał problemy, które deweloper uwzględnił w następnej wersji poprawek.

Linux kompiluje się znacznie szybciej

Założyciel i redaktor naczelny Phoronix, Michael Larabel, przetestował te poprawki na serwerze z dwoma procesorami Epyc 9575F („Turyn”) i czwartą konstrukcja jądra zawierającego obecnie prawie 41 milionów linii kodu. Każdy z procesorów ma 64 rdzenie i 128 wątków, więc cała platforma oferuje 128 rdzeni i 256 wątków.

System testowy Phoronix zbudował standardowe jądro x86-64 (defconfig) z poprawkami w ciągu 15 do 17 sekund, w zależności od konfiguracji, zamiast poprzednich 22 sekund. Najlepszy wynik osiągnięto w trybie zarządzania poborem mocy procesorów Epyc. 

Czas kompilacji allmodconfig z włączonymi wszystkimi modułami skrócił się ze 169 do 134 sekund. Ta wartość jest bardziej znacząca w praktyce, ponieważ jądro dystrybucyjne z tysiącami modułów jest bliższe allmodconfig niż standardowemu jądru w wersji uproszczonej.

Największe korzyści widać przy małych zmianach

Nie trzeba jednak posiadać serwera z setkami wątków, żeby zauważyć różnicę. Stoakes sprawdził poprawki także na komputerze Apple z procesorem M2.

Na komputerze Apple M2 z systemem Linux, poprawki Kbuild przyspieszają kompilacje przyrostowe o 55% w Clang i o 45% w GCC, według Stoakesa, podczas gdy pełna kompilacja Clang przyspiesza jedynie o około 10%. Kompilacje bez operacji (no-op), czyli ponowne tworzenie na już skompilowanym drzewie źródłowym, są skrócone o 74–76%.

Linux 7.4 może dostać te poprawki

Zmiany Stoakesa trafiły już do gałęzi kbuild-for-next. O ich dalszym losie zdecyduje proces integracji zmian przed Linuksem 7.4. Na razie nie ma gwarancji, że cała seria zostanie zaakceptowana w obecnej formie. Jeśli jednak poprawki przejdą proces przeglądu i trafią do głównej gałęzi, szybsza kompilacja jądra będzie dostępna dla znacznie szerszego grona użytkowników.

Na tym możliwości się nie kończą. Michael Larabel ocenia, że nowszy AMD Epyc 9686F oparty na architekturze Zen 6 może zejść z czasem budowy standardowego jądra poniżej 10 sekund. To jednak prognoza dotycząca konkretnej, bardzo wydajnej platformy, a nie wynik osiągnięty w obecnym teście. Michael Larabel celowo wybiera model F o wysokim taktowaniu zamiast 256 rdzeni: Dopóki GCC nie kompiluje równolegle poszczególnych plików źródłowych, dodatkowe rdzenie oferują jedynie ograniczone korzyści. Odpowiednie poprawki pozostają nieukończone od lat.