Ядро Linux 7.2 было помечено тегом и выпущено на этой неделе по обычному графику.
Этот цикл разработки стал одним из самых насыщенных за всю историю проекта — больше изменений было внесено только в цикле 6.7. Такая интенсивность уже считается «новой нормой»: последние 3-4 цикла были довольно напряжёнными, особенно в части исправлений. Среди заметных достижений цикла — планировщик с учётом кэша, улучшения MGLRU, концепция суб-планировщиков для sched_ext (хорошее введение в тему у LWN), автоматическое создание transparent hugepages разного размера (также неплохо описано на LWN) и многое другое — полную картину можно увидеть в статьях LWN (часть 1 и часть 2).
Igalia, как обычно, внесла значительный вклад — прежде всего это fair-политика планировщика DRM, для которой в последний момент была зафиксирована регрессия (подробнее ниже), поэтому она включена как опциональная. Помимо этого, в ядро попало удобное runtime-управление питанием GPU для Raspberry Pi 4 и 5, улучшения sched_ext, futex и общие исправления багов. Разберём основные моменты.
Изменения от Igalia
Fair-политика планировщика DRM
В этом цикле планировалось внедрить и включить по умолчанию fair-политику планировщика DRM, которая заметно улучшает ситуацию в сценариях, когда GPU делят несколько клиентов, а также когда лёгкий интерактивный клиент конкурирует за GPU с ресурсоёмким. Однако из-за отчёта о регрессии, поступившего в последний момент во время недели 7.2-rc7, политикой по умолчанию осталась старая схема FIFO (first-in/first-out). Исправление для регрессии fair-политики уже известно, а ранние тесты выглядят многообещающе, так что есть надежда на её повторное включение в одном из следующих релизов ядра.
sched_ext
Улучшена наблюдаемость sched_ext для упрощения отладки. Когда пользовательский планировщик sched_ext сталкивается с ошибкой времени выполнения — например, не может запланировать задачу более 30 секунд, — ядро исключает его и возвращается к планировщику по умолчанию. Чтобы упростить диагностику таких сбоев, ядро выводит дамп состояния каждого CPU. Однако, особенно на системах с большим числом ядер, эти дампы могут обрезаться из-за ограничений размера буфера между пространством ядра и пользовательским пространством. Проблему смягчили, отдав приоритет CPU, вызвавшему сбой (exit CPU) — теперь его дамп выводится первым, а его идентификатор напрямую передаётся BPF-планировщикам и инструментам пользовательского пространства.
Управление питанием GPU Raspberry Pi и не только
В этом релизе появилась поддержка runtime power management для GPU Raspberry Pi 4 и 5.
До сих пор драйвер V3D использовал очень простую модель питания: тактовый генератор GPU включался при инициализации драйвера и оставался включённым на протяжении всего его жизненного цикла. Хотя такой подход был простым и работоспособным, он означал, что простаивающий GPU всё равно потреблял энергию, даже не выполняя никаких задач.
С runtime PM питание на GPU подаётся только тогда, когда он действительно обрабатывает работу, а его тактовый генератор можно отключать в периоды простоя. Это снижает энергопотребление, когда Raspberry Pi не использует GPU. Об этой функции написан отдельный пост в блоге с подробностями и результатами замеров энергопотребления.
Также исправлены два давних бага в драйвере GPU Raspberry Pi 3, которые годами преследовали пользователей RetroPie, вызывая случайные зависания GPU и полные краши системы. Проблемы были связаны с тем, как ядро обрабатывало память тайлов при нехватке места у GPU во время обработки кадра. Исправления гарантируют, что каждая графическая задача записывает данные только в свою область памяти, а переиспользуемая память должным образом очищается перед повторным использованием — это предотвращает попадание устаревших или повреждённых данных в GPU. С этими исправлениями пользователи RetroPie больше не должны сталкиваться с крашами, которые могли возникать при навигации по меню.
Наконец, внесён ряд исправлений для сброса GPU на Raspberry Pi 4 и 5, сделавших процесс сброса более надёжным и предсказуемым.
Тесты и документация futex
Продолжается работа по улучшению и поддержке futex() — важного системного вызова, который используется во всех видах нагрузок для создания механизмов синхронизации. В этом цикле помогли спроектировать и внедрить решение 14-летнего бага, который в некоторых пограничных случаях приводил к повреждению данных в механизме robust list.
Общие исправления
Исправлена давняя проблема в драйвере ueagle-atm, которая могла приводить к состоянию гонки между операциями создания и удаления kernfs при инициализации и отключении устройства через API request_firmware, и годами порождала отчёты об ошибках в syzbot.
Также улучшена корректность реализации memcmp() на встроенном ассемблере, используемой при загрузке x86, — это предотвращает потенциальные тонкие ошибки из-за оптимизаций компилятора и переупорядочивания инструкций.
На пути к полной поддержке HDMI 2.1
Часть поддержки HDMI 2.1 Fixed Rate Link (FRL), вошедшей в эту версию, восходит к работе Родриго Сикейры из Igalia, выполненной ещё во время его работы в AMD. Эта работа реализует базовую поддержку, позволяющую драйверу amdgpu взаимодействовать с мониторами HDMI 2.1 (в первую очередь реализацию FRL). Код существовал отдельно от основного дерева на протяжении нескольких лет, прежде чем был включён в исходный код: часть фрагментов сохранена практически в первоначальном виде, другие были переработаны по ходу процесса. У Igalia есть опыт работы с различными драйверами DRM/KMS, и этот практический опыт с функциями HDMI 2.1 дополняет знания, необходимые производителям для внедрения передовых возможностей в собственные драйверы.