Ускорение процесса сборки ядра

[krasnyh]

Итог

только добавил aufs. Т.е. остальное как у автора pf

Наверно уже больше 2 часов компилилось? Все же нормально, это когда 10-15 мин, но так долго... На лицо не целевое использование домашнего компа. )

Полезно будет доустановить пакет ccache и включить его в makepkg.conf. Сократится время повторной сборки, например, когда сборка прерывается и правятся ошибки или, как в данном случае, компилится одно ядро, но с разным конфигом.

[krasnyh]

Еще очень сильно зависит от потоков -j. Часто считают достаточным выставлять make -j $(( $(nproc) + 1 )), но некоторые идут дальше.


Например, в этом тесте от hakavlad, -j 128. Понятно, что в первую очередь здесь тестирование отзывчивости памяти и, возможно, именно такие высокие значения он не ставит при компиляции, но кто знает...

Коммент под статьей "Сборка и компилирование ядра Linux"

СОВЕЕЕЕТ!!!!
при компилировании я всегда использую следующий прием
вместо make "команда"
я использую
make -j"количество ядер помноженное на 2 и + 1" "команда"

Ускоряет компиляцию ядра linux В РАЗЫ,

[sfs]

$(nproc) + 1

В моем PKGBUILD так и сделано

Ускоряет компиляцию ядра linux В РАЗЫ

А куда торопиться-то. Если еще работаете на этом пк - наоборот лучше занизить к-во потоков

[krasnyh]

В моем PKGBUILD так и сделано

Код

% grep MAKEFLAGS /etc/makepkg.conf
MAKEFLAGS="-j5"

[krasnyh]

Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%

При полной пересборке ядра командой "make -j96 vmlinux" на тестовой систем применение патчей показало сокращение времени сборки ветки v5.16-rc7 с 231.34 до 129.97 секунд (с 15.5 до 27.7 сборок в час), а также повысило эффективность использования ядер CPU во время сборки. При инкрементальной сборке эффект от оптимизации ещё более заметен - время повторной пересборки ядра после внесения изменений в заголовочные файлы сократилось в разы (от 112% до 173% в зависимости от изменяемого заголовочного файла). Оптимизации пока доступны только для архитектур ARM64, MIPS, Sparc и x86 (32- и 64-бит).

p.s.  Кстати, "make -j96 vmlinux" как отсылка к моему посту.

Полезно будет доустановить пакет ccache и включить его в makepkg.conf. Сократится время повторной сборки, например, когда сборка прерывается и правятся ошибки или, как в данном случае, компилится одно ядро, но с разным конфигом.

[sfs]

Часто считают достаточным выставлять make -j $(( $(nproc) + 1 )), но некоторые идут дальше.

Я ускорения не заметил.
ccache - тоже. Создает здоровый кэш в хомяке (который у меня в tmpfs). Как минимум неудобно
Заметно ускорение на ssd вместо hdd
И при повторной компиляции  с другим конфиком - не удаляйте src - меняйте /src/.config  и makepkg -e . Чем меньше разница между конфигами - тем быстрее скомпилится. Как я понял частично используются ранее скомпиленные *.o

[krasnyh]

ccache - тоже

Как я понял частично используются ранее скомпиленные *.o

Ну так, потому что включен ccache. Разве нет?

[sfs]

потому что включен ccache. Разве нет?

Без него

частично используются ранее скомпиленные *.o

Там где я его использовал дополнительно к этой методе - улучшения не заметил.

[krasnyh]

Без него

Без него, каждая повторная компиляция будет с нуля, не зависимо что там уже собрано. Или с каких-то пор теперь по-другому в линукс?

[sfs]

Компилил ядро без ccache не удаляя src несколько дней. Последний раз 4го. В src тем не менее .o от 2 и 3го числа
 Тут не уверен. Может при разных конфигах  некоторые  о  не использубтся

Но если удалить src  компилится в 2 раза дольше
Тут чисто мой опыт. Побочек пока не выявил

[krasnyh]

Использование ссache может значительно ускорить сборку некоторых пакетов или проектов, которые компилируются несколько раз, так как заново компилироваться будут только файлы, которые изменились с последней компиляции.

При компилировании какого-либо файла вычисляется его хеш и, если такой файл уже присутствует в реестре скомпилированных файлов, то он не будет компилироваться заново, а будет использоваться старый бинарный файл. Это может ускорить сборку некоторых пакетов в 5—10 раз.

При этом учитываются разные версии компилятора и опции сборки. Это означает, что, если вы однажды собрали проект с оптимизацией -О2, использовав при этом ссache, то при сборке с оптимизацией -О3 файл будет компилироваться заново, при этом в реестре ссache старый файл сохранится, но добавится и новый.

https://ru.wikipedia.org/wiki/Ccache

[krasnyh]

Создает здоровый кэш в хомяке (который у меня в tmpfs). Как минимум неудобно

Местоположение можно изменять, ссылка. А так же, ограничить размер, ссылка.

[sfs]

https://ru.wikipedia.org/wiki/Ccache

По теории красиво. Как на практике - я написал. Перепроверьте - был сосредоточен не на Ccache. Мог что-то упустить
Ну и час - 2 . Надо не часто. На фоне можно работать. Надо ли усложнять...
Тем более при отлаженных конфигах несколько раз компилить не придется

[sfs]

Еще посмотрел - даже  некоторые .ko от 3го числа, но в итоговом пакете их нет
Получается

Может при разных конфигах  некоторые  о  не использубтся