Сборка ядра Linux на мощной рабочей станции уже уложилась примерно в 15 секунд, а следующая цель выглядит почти неприлично: меньше 10 секунд для чистого defconfig-билда x86-64. Для разработчиков это не просто спортивный бенчмарк на железе стоимостью как небольшая серверная стойка: ускорение пришло не только от ядер CPU, но и от расчистки узких мест в Kbuild, в том числе с помощью AI/LLM.
О результатах сообщает Tom's Hardware со ссылкой на тесты и комментарии главы Phoronix Майкла Ларабела. Он много лет использует время компиляции ядра как один из характерных Linux-бенчмарков: раньше такая задача была честным поводом уйти за кофе, теперь, по его формулировке, это скорее пауза на глоток. Ирония тут уместна: бенчмарк старый, но вывод свежий — параллельная сборка начинает лучше раскрывать современное многоядерное железо.
Главная цифра: после свежих v4-патчей разработчика Linux MM Лоренцо Стоукса чистая сборка defconfig-ядра x86-64 на системе Ларабела заняла около 15 секунд. До этих изменений тот же тест на той же машине занимал больше 22 секунд. То есть выигрыш получился не косметическим, а примерно на треть, причем без агрессивного трюка с RAM-диском.
Конфигурация тестовой машины, правда, быстро охлаждает фантазии владельцев обычных ноутбуков. В системе стояли два AMD EPYC 9575F по 64 ядра каждый, всего 128 ядер и 256 потоков, 24 модуля DDR5-6400 по 64 ГБ, NVMe-накопитель Samsung PM1743 на 3,84 ТБ с PCIe 5.0 и стандартная Ubuntu 26.04 LTS. Домашний ПК, даже очень приличный, скорее всего все еще оставит время не только нажать кнопку чайника, но и пожалеть о ценах на память.
Но в этой истории важнее не абсолютные 15 секунд, а то, почему они стали возможны. По данным источника, в Kbuild убрали ряд bottleneck-ов, которые мешали сборке масштабироваться на большое число потоков. Такие проблемы знакомы не только ядру: в крупных проектах компиляция часто упирается не в суммарную мощность CPU, а в последовательные шаги, генерацию зависимостей, скрипты конфигурации, файловую систему или старые предположения build-системы о том, сколько ядер у разработчика вообще может быть.
Сборка ядра Linux давно стала удобным тестом для процессоров именно потому, что она сочетает много мелких операций, работу компилятора, зависимостей и ввода-вывода. Если этот сценарий начинает лучше распараллеливаться, выигрывают не только владельцы двухсокетных EPYC-систем. Даже более скромные процессоры могут получить заметное ускорение, если из цепочки убирают шаги, где один поток заставлял остальные простаивать и смотреть в потолок.
Есть и второй, более тяжелый режим: allmodconfig, где включаются тысячи драйверов и подсистем. На той же машине Ларабела свежие патчи сократили время такой сборки со 169 до 134 секунд. Это уже не магические 15 секунд, но рубеж около двух минут для максимально насыщенной конфигурации ядра выглядит не менее любопытно. Особенно если помнить, что речь идет не о синтетике с искусственно облегченной файловой подсистемой, а о тесте без RAM-диска.
Отдельная деталь — роль AI/LLM в оптимизации. Источник не описывает это как историю про автопилот, который сам переписал Linux. Скорее речь о практичной помощи в поиске и подготовке изменений, которые затем проходят обычный инженерный фильтр. На фоне споров вокруг ИИ в разработке ядра это хороший пример более приземленного сценария: не замена мейнтейнеров, а ускоритель для анализа скучных, но дорогих по времени узких мест.
Для бизнеса и команд разработки вывод простой: стоимость ожидания в CI, локальных сборках и проверках растет незаметно, пока ее не начинают считать. Если ядро Linux можно ускорить за счет пересмотра build pipeline, то корпоративные монорепозитории, мобильные приложения и backend-платформы тоже имеют шанс найти свои 30% не только в покупке новых серверов. Иногда дешевле сначала спросить, почему 256 потоков загружены не полностью.
Следующий ориентир — сборка ядра Linux быстрее 10 секунд. Phoronix уже связывает этот рубеж с будущими системами на AMD Zen 6 EPYC 9686F, MRDIMM-памятью и PCIe Gen6-накопителями, но это пока прогноз, а не измеренный факт. Самый интересный вопрос теперь не в том, кто первым покажет красивую цифру, а сколько таких оптимизаций из мира ядра доберется до обычных проектов, где разработчики все еще успевают не только заварить кофе, но и забыть, зачем запускали сборку.