Szybsza budowa kernela

[linusen]

Witam, jak odchudzić kernel Linux podczas kompilacji? Nie znam się na sprzęcie tak jak Linus Torvalds do tej pory udało mi się zejść do 14 minut. Wiem że kompiluję jeszcze dużo sterowników które nie są potrzebne na mój hardware, więc marnuję dużo energii na kompilację niepotrzebnych sterów.

Według tej strony mój procesor powinien skompilować kernel w 188 sekund a nie 14 minut. Z jakich narzędzi korzystacie aby przyspieszyć wykrywanie sprzętu przez kernel który istnieje fizycznie?
https://openbenchmarking.org/test/pts/build-linux-kernel-1.16.0

Dla przykładu Linus kiedyś narzekał że jego kompilacja kernela 6.8 wydłużyła się z 22 sekund do 40 sekund. Ale Torvalds dobrze zoptymalizował proces kompilacji Linuksa na Fedorze.
https://www.phoronix.com/news/Torvalds-Perf-Regression-Fix
https://www.phoronix.com/news/Linux-6.8-Sched-Regression

https://www.reddit.com/r/linux/comments/uiotu/linus_torvalds_has_optimized_the_linux_build/

Ostatnio czytałem że niektóre nowe systemy jak RedoxOS, SerenityOS tak ułatwiają kompilację swoim developerom że mają wbudowane w kernel jakieś opcje które wykrywają tylko faktyczny sprzęt i podzespoły które posiada twój komputer.

Nie wiem czy developerzy Gentoo mają jakieś lepsze narzędzia i programy do wykrywania hardware, które ułatwiają im i przyspieszają kompilację tylko niezbędnych sterowników. I są dostępne na inne dystrybucje Linuksa?

[linux4ever]

https://www.linuxfromscratch.org/lfs/view/development/chapter10/kernel.html

Tu jak skompilować poprawnie.

I aby znaleźć wszystkie flagi make wpisz w terminalu man make

Oraz najważniejsze make -j

-j [jobs], --jobs[=jobs]
            Specifies the number of jobs (commands) to run simultaneously.  If there is more than one -j option, the last one is effective.  If the -j option is given without an argument,  make  will  not
            limit  the  number  of  jobs  that  can  run  simultaneously. When make invokes a sub-make, all instances of make will coordinate to run the specified number of jobs at a time; see the section
            PARALLEL MAKE AND THE JOBSERVER for details


PARALLEL MAKE AND THE JOBSERVER
       Using the -j option, the user can instruct make to execute tasks in parallel. By specifying a numeric argument to -j the user may specify an upper limit of the number of parallel tasks to be run.

       When  the  build environment is such that a top level make invokes sub-makes (for instance, a style in which each sub-directory contains its own Makefile ), no individual instance of make knows how
       many tasks are running in parallel, so keeping the number of tasks under the upper limit would be impossible without communication between all the  make  instances  running.  While  solutions  like
       having  the  top  level  make  serve  as a central controller are feasible, or using other synchronization mechanisms like shared memory or sockets can be created, the current implementation uses a
       simple shared pipe.

       This pipe is created by the top-level make process, and passed on to all the sub-makes. The top level makeprocesswrites N-1 one-byte tokens into the pipe (The top level make is assumed  to  reserve
       one  token  for  itself). Whenever any of the make processes (including the top-level make ) needs to run a new task, it reads a byte from the shared pipe. If there are no tokens left, it must wait
       for a token to be written back to the pipe. Once the task is completed, the make process writes a token back to the pipe (and thus, if the tokens had  been  exhausted,  unblocking  the  first  make
       process that was waiting to read a token).  Since only N-1 tokens were written into the pipe, no more than N tasks can be running at any given time.

       If  the  job  to  be  run  is not a sub-make then make will close the jobserver pipe file descriptors before invoking the commands, so that the command can not interfere with the jobserver, and the
       command does not find any unusual file descriptors.

[linusen]

Dzięki za odpowiedź ale kompilować ogólnie kernel to ja potrafię. Problem jest z tym jak to wszystko co niepotrzebne dokładnie wyszukać, czy są do tego jakieś programy konsolowe usuwające wszystko z pliku config poza naszym sprzętem? Dodaję do liczby wątków procesora trochę więcej aby wykorzystać całą moc procesora podczas kompilacji np jak procesor jest 4 rdzeniowy z 8 wątkami to daje time make -j9
https://unix.stackexchange.com/questions/253245/what-does-make-localmodconfig-do
https://wiki.archlinux.org/title/Modprobed-db

Obecnie kernel nie posiada chyba takich narzędzi jak inne nowoczesne systemy powstałe po 2015 roku napisane w nowszych językach niż C. Jak ktoś nie jest developerem kernela jak Linus i programistą sterowników, to musi wszystko samemu sprawdzać pasmem prób i błędów kompilacji, jak użytkownicy Gentoo.

Zależy mi na zejście z kompilacją do 3 minut czyli tych 188 sekund. Torvalds zapewne wsuwa wszystkie swoje karty na usb i za pomocą ls sprawdza i kompiluje tylko to co mu jest potrzebne, stąd na 32 rdzeniowym Ryzenie to 19 sekund kompilacji, choć pewnie jego pierwsza kompilacja trwała znacznie dłużej.

[linux4ever]

Dzięki za odpowiedź ale kompilować kernel to ja potrafię. Dodając do liczby wątków procesora trochę więcej aby wykorzystać całą moc procesora podczas kompilacji np jak procesor jest 4 rdzeniowy z 8 wątkami to daje time make -j9

Jeszcze jest parametr -O3 to optymalizuje kod ale aby go użyć musiałbyś użyć go w pliku makefile.

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Z tym że nie wiem czy ręczne edytowanie pliku jest dobre dla psychiki.

Może przez grep się da lub sed albo awk.

[robson75]

Od ponad 3 lat buduje kernel przy pomocy modprobed-db, jest to narzędzie które wyszukuje aktywnie załadowane moduły, tworzy listę i według niej jest budowane jajo, bez zbędnych śmieci. Ale jest ono dostępne tylko dla systemu Arch Linux.

[linusen]

Sama taka optymalizacja zbyt dużo nie da, trzeba wiedzieć co wywalić, które karty graficzne(to najprostsze), sterowniki wifi, sterowniki do klawiatury i myszy. Istnieją jakieś polecenia optymalizujące z Gentoo, Slackware które wyświetlą ci które driverki i sterowniki najdłużej się kompiluje?

No właśnie modprobed-db nie działa na Ubuntowatych, a developerzy Slackware, Gentoo, Archa mają do tego różne narzędzia ułatwiające kompilację, dlatego je wymieniłem w linkach, te niektóre.

Czy możesz napisać na jakim procesorze i na ilu ramach budujesz kernel oraz i ile opcja time make podaje ci minut?

[Piotr_1988]

Witam, jak odchudzić kernel Linux podczas kompilacji? Nie znam się na sprzęcie tak jak Linus Torvalds do tej pory udało mi się zejść do 14 minut. Wiem że kompiluję jeszcze dużo sterowników które nie są potrzebne na mój hardware, więc marnuję dużo energii na kompilację niepotrzebnych sterów.

Według tej strony mój procesor powinien skompilować kernel w 188 sekund a nie 14 minut.

Problem tkwić może w czymś innym. U mnie na GNOME 46 na Fedorze 40 czas kompilacji różnych programów zmienia się kilkukrotnie w zależności od tego, jaki Power Mode mam w danej chwili włączony. Mam dostępne trzy z domyślną konfiguracją: Performance, Balanced, Power Saver. Nie wiem, czy jest to Twój przypadek, ale rozwiązanie może być trywialne.

[robson75]

Czy możesz napisać na jakim procesorze i na ilu ramach budujesz kernel oraz i ile opcja time make podaje ci minut?

Intel i5-10400F 16 GB ram, budowa mi zajmuje niecałe 10 min.

[linusen]

Tak Gnome jest dość ociężałe w porównaniu do innych środowisk graficznych i menadżerów okien, ale aż tak bardzo nie obciąży procesora żeby było widać takie duże różnice przy kompilacji. Najlepsi spece od Linuksa po prostu usuwają wszystko czego nie używają. Z tego co wiem Linus znowu używa Fedory z Gnome i kompiluje na Ryzenie w 19 sekund, zapewne wyłącza przeglądarkę i inne programy aby jak najszybciej skompilować z całą mocą procesora.

https://www.youtube.com/watch?v=JvuDrrFHrhQ

Znalazłem tutaj na openbenchmarking test z tym procesorem i5-10400F i on skompilował w 134 sekundy. Wychodzi więc na to że modprobed-db nie usuwa tak dobrze wszystkich śmieci i jest jeszcze sporo do zoptymalizowania w kernerze Linux.
https://openbenchmarking.org/test/pts/build-linux-kernel&eval=2e091b8032ec35a1fdb1b678beec9531ea9c956b#metrics

W sumie to trzeba patrzeć na wyniki w Build: allmodconfig, a nie w Build: defconfig. I według tego pierwszego mój procesor kompiluje kernel w 21 minut, a ja poprzez swoje optymalizacje uzyskałem o 7 minut lepszy wynik.

[robson75]

Znalazłem tutaj na openbenchmarking test z tym procesorem i5-10400F i on skompilował w 134 sekundy. Wychodzi więc na to że modprobed-db nie usuwa tak dobrze wszystkich śmieci i jest jeszcze sporo do zoptymalizowania w kernerze Linux.

To zależy jak go budował, od samego początku buduje linux-tkg który to zawiera wiele patch-ów i jest odpowiednio zoptymalizowany.

[Piotr_1988]

Tak Gnome jest dość ociężałe w porównaniu do innych środowisk graficznych i menadżerów okien, ale aż tak bardzo nie obciąży procesora żeby było widać takie duże różnice przy kompilacji. Najlepsi spece od Linuksa po prostu usuwają wszystko czego nie używają. Z tego co wiem Linus znowu używa Fedory z Gnome i kompiluje na Ryzenie w 19 sekund, zapewne wyłącza przeglądarkę i inne programy aby jak najszybciej skompilować z całą mocą procesora.

Nie pisałem, że Gnome jest ociężałe tylko, że czas kompilacji programów zmienia się w zależności od ustawień zarządzania energią. Jeśli programuję, przełączam Power Mode -> Performance. Wtedy dowolny kod kompiluje się kilkukrotnie szybciej. Nie ma potrzeby wyłączania innych programów i nie chodzi o "wagę środowiska".

[linusen]

W tamtym okresie jeszcze nie robili testu Build: allmodconfig z twoim procesorem, dopiero od 1.13.x to podzielili ale już z innymi prockami. Twój procesor jest trochę szybszy od mojego ale i tak uzyskałeś dobry wynik.
Z tego co piszą w kernelu 6.8 był spadek wydajności, chyba to poprawili ale z każdym nowym wydaniem te kernele robią się coraz bardziej ociężałe. Może to przez to że dodali nowy język programowania do GCC.

Nie używam Gnome to nie wiem o tych opcjach zarządzania energią, ale Torvalds zapewne wybiera te najszybszą, gdy chce jak najszybciej skompilować kernel..