Разбор беспорядка, который накапливался в коде десятилетиями  — занятие не для слабонервных, но ведущий разработчик ядра Linux Инго Молнар постарается попробовать разобрать.

В прошлом году исходный код Linux набрал  27,8 миллионов строк кода. Как и любой другой программный проект, особенно с 30-летней историей, Linux за эти годы вобрал в себя некоторую долю беспорядка. После нескольких месяцев работы, старший разработчик ядра Linux Инго Молнар выпустил свои первые наработки по очистке ядра на фундаментальном уровне с помощью его проекта «Fast Kernel Headers».

Какова цель? Ни много ни мало — полная очистка и переработка иерархии заголовков ядра Linux и зависимостей заголовков. Linux содержит много заголовочных файлов .h. Если быть точным, то в ядре Linux около 10 000 основных заголовков .h с иерархиями include/ и arch/*/include/.

Как объяснил Мольнар: «За последние 30 с лишним лет они превратились в сложный и болезненный набор перекрестных зависимостей, которые мы с любовью и трепетом называем «адом зависимостей»».

Чтобы придать всему этому смысл и рифму, Молнар предлагает внести в код 2200 коммитов (правок). Это много коммитов! Почему так много? По мнению Мольнара, оказывается, что во всем этом коде намного больше беспорядка, чем он думал, когда начал свой проект по очистке в конце 2020 года. Если быть точным:

Когда я начинал этот проект в конце 2020 года, я ожидал, что там будет 50-100 патчей. Я провел несколько грубых измерений, которые показали, что увеличение скорости сборки на 20% может быть достигнуто за счет уменьшения зависимостей заголовков без существенного влияния времени выполнения на ядро. Казалось достаточно существенным, чтобы оправдать 50-100 коммитов.

— Но по мере того, как количество патчей увеличивалось, я наблюдал лишь ограниченное увеличение производительности. К середине 2021 года я получил более 500 коммитов в этом дереве, и мне пришлось замахнуться на более высокую планку. Первые два подхода просто не масштабировались, не обслуживались и едва ли предлагали ускорение сборки на 4%.

— С третьей попытки я представил механизм per_task (), который обеспечил необходимую гибкость для значительного уменьшения зависимостей, и это был подход намного улучшающий удобство сопровождения. Но даже после 1000 коммитов я едва смог увеличить скорость сборки на 10%. Опять же что-то всё равно не давало мне покоя. 

— Цифры были довольно ясными: 20% прирост производительности был вполне допустим. Поэтому осенью 2021 года я продолжал совершенствовать это дерево, и большинство показателей по скорости начали поступать после более чем 1500 коммитов . Я был очень удивлен, когда оно достигло 20% ускорения в сравнении с моей эталонной конфигурацией. Существовала явная взаимосвязь между улучшением накладных расходов на сборку ядра и количеством зависимостей, когда они сокращаются до минимума.

Итак, сегодня его очищенное «дерево быстрых заголовков» предлагает +50-80% улучшение производительности сборки ядра на поддерживаемых архитектурах, в зависимости от конфигурации. Это большой шаг вперед с точки зрения эффективности и производительности сборки ядра Linux. 

Улучшение от 50 до 80% стоит потраченного времени и усилий. Эта экономия скорости достигается за счет уменьшения размера заголовков по умолчанию.

Но подождите, эти 2200 коммитов — только верхушка айсберга. Эти изменения коснутся почти всех программ в ядре Linux. В целом, по оценке Молнара, «помимо вышеупомянутых 25 поддеревьев и 2200 коммитов, дерево быстрых заголовков изменяет более половины всех существующих исходных файлов ядра». Он изменит 25 288 файлов при 178 024 вставках и 74 720 удалениях. Другими словами: «Да, это, вероятно, самое крупное обновление в истории LKML [Linux Kernel Mailing List] .»

Вдобавок к этому, чтобы сделать эти изменения выполнимыми, потребуется агрессивное разделение высокоуровневых заголовков; разделение типа и заголовка API; автоматическое добавление зависимостей в файлы .h и .c; и оптимизация заголовков. Это будет не просто. Итак, прежде чем нажать на курок и начать вносить эти изменения, Молнар собирает отзывы от своих товарищей по сопровождению, и, в частности, он хотел бы услышать мнение Линуса Торвальдса, Эндрю Мортона и других разработчиков подсистем ядра, затронутых этими изменениями.

Грег Кроа-Хартман, специалист по сопровождению ядра Linux в стабильной ветке Linux, считает: «Это интересно но как вы собираетесь синхронизировать определения kernel/sched/per_task_area_struct_defs.h и struct task_struct_per_task? Короче говоря, кто будет отвечать за поддержание всех этих изменений?»

Мольнар ответил, что готов взяться за эту работу и не думает, что это вызовет такие большие проблемы. Затем Кроа-Хатман благословил усилия Мольнара и заметил: «Я оставлю все это на усмотрение разработчиков планировщика, но мне это все равно кажется странным, когда я задумываюсь о беспорядке, который мы создаем, пытаясь решать проблемы в C».

Это одна из причин, почему предпринимаются попытки сделать Rust Linux вторым языком.

В случае принятия пользователи не увидят никаких реальных изменений. Но разработчики ядра и дистрибутивов Linux смогут компилировать Linux быстрее, чем когда-либо. В результате будет проще и быстрее, чем когда-либо, вносить улучшения, исправлять и добавлять функции в Linux.