Линус Торвальдс воспользовался ролью великодушного пожизненного диктатора Linux и объявил о своём решении перенести код расширяемого планировщика (extensible scheduler) sched_ext (патчи sched_ext v6) в рабочую ветку Linux 6.11 (находится в разработке, текущий релиз Linux 6.9), хотя против этого действия были некоторые мейнтейнеры проекта. Торвальдс считает, что код sched_ext достаточно готов и представляет реальную ценность для основного ядра Linux. По его мнению, не стоит тянуть с sched_ext, продолжая работать с этим компонентом вне рабочей ветки будущей версии ядра Linux.
По данным Phoronix, код sched_ext оказался достаточно универсальным для повышения производительности игр в Linux, более быстрого прототипирования новых изменений планировщика, а разработчики из Ubuntu/Canonical высоко оценили этот проект на предмет микроядерного дизайна и многих других интересных подходов при работе с Linux. Тем не менее, эта разработка оставалась долгое время вне основной ветки, но сейчас ситуация меняется с предстоящим циклом разработки Linux 6.11.
Это патчи с реализацией механизма "sched_ext" (SCX), позволяющие использовать eBPF для создания планировщиков CPU, охватывающие практически все аспекты планирования выполнения задач и распределения ресурсов CPU. Подобные планировщики могут загружаться динамически и выполняться внутри ядра Linux в виртуальной машине eBPF, в которой, благодаря применению JIT-компиляции, байткод транслируется в машинные инструкции и выполняется с производительностью скомпилированного кода.
Предложенные патчи реализуют новый класс планирования SCHED_EXT, для которого выставлен приоритет вызова ядром между классами SCHED_IDLE и SCHED_NORMAL, что не позволяет в BPF-обработчиках, привязанных к SCHED_EXT, повлиять на задачи, уже прикреплённые к штатному планировщику задач (SCHED_NORMAL), но даёт возможность прикрепления к SCHED_EXT отдельных задач или перемещения для обработки с его помощью всех процессов, имеющих приоритет ниже выполнения в режиме реального времени. Если к SCHED_EXT не привязаны BPF-обработчики, то все процессы, перемещённые в класс SCHED_EXT, будут обрабатываться при помощи планировщика SCHED_NORMAL. Работа BPF-обработчиков сводится с разбору очередей задач, ожидающих выполнения на CPU (одна глобальная очередь и по одной очереди на ядро CPU), и выбора задачи, которой следует предоставить ресурсы CPU при освобождении очередного ядра CPU.
Механизм sched_ext упрощает создание специфичных для определённых задач планировщиков, даёт возможность экспериментировать с различными техниками и стратегиями планирования, а также позволяет быстро создавать рабочие прототипы и заменять планировщики на лету в рабочих инфраструктурах. Например, при помощи sched_ext можно создать планировщик, учитывающий специфику определённого приложения и динамически меняющий стратегию планирования его выполнения в зависимости от состояния системы и каких-то дополнительных факторов.
Честно говоря, я не вижу причин больше откладывать это. Весь этот набор исправлений был основным (частным) обсуждением на прошлогоднем саммите разработчиков ядра, и я не вижу никакой ценности в таком же обсуждении (будь то вне списка или в качестве фактическоего события) на предстоящем саммите сопровождающих год спустя, поэтому, чтобы добиться какого-либо разумного прогресса, мой текущий план — объединить это для версии 6.11.
По крайней мере, в этом отношении мы добиваемся прогресса, и обсуждение на KS 2024 может быть посвящено моей остроте ума – или ее отсутствию – а не перефразированию того же самого, что явно не принесло никакого прогресса в прошлом году.
Я никогда не был большим сторонником попыток сделать всех счастливыми с помощью кода, находящегося вне основной ветки — нам лучше работать над ним вместе, внутри ветки.
И использование аргумента «чтобы принять это, сначала нужно исправить что-то еще» тоже не очень хорошо работает (и это обсуждалось более десяти лет на различных саммитах сопровождающих проекта).
Возможно, разработчики, у которых есть опасения по этому поводу, смогут поработать над этими проблемами, когда это будет внутри ветки проекта.
Я также не верю в аргумент, который использовался (несколько раз) о том, что BPF scheduler будет препятствовать участию мейнтейнеров в дальнейшей разработке кода планировщика. Лично я считаю, что главное, что удерживает разработчиков от участия, — это слишком высокие барьеры для участия.
В любом случае, я обращаюсь к Tejun с просьбой просто отправить мне запрос на включение для следующего окна слияния.
И для всех остальных как предупреждение: «Это происходит». [Пожалуйста, просто мысленно вставьте сюда гифку-мем «ЭТО ПРОИСХОДИТ» — потому что, если бы я действительно включил его сюда, lkml просто отклонил бы это письмо. Иногда анти-html правила работают не в нашу пользу].
Линус.
Таким образом, если не считать каких-либо изменений планов в последнюю минуту в период с настоящего момента до середины июля, когда откроется окно слияния Linux 6.11, патчи для sched_ext появятся в следующем цикле разработки ядра Linux.
В мае Торвальдс в переписке в списке рассылки по поводу обсуждения возможности смягчения неожиданных арифметических переполнений/недополнений/зацикливания в исходном коде C ядра Linux посоветовал Кису Куку из Google быть решением, а не проблемой в рамках работы с мейнтейнерами ядра Linux, а также перестать плодить неразумные жалобы на код компилятора.
12 января 2024 года Линус Торвальдс обозвал %^!@$% новый код Intel Xe для DRM (Direct Rendering Manager) в Linux 6.8. Он сам исправил его огрехи и призвал сторонних разработчиков и мейнтейнеров проекта тестировать, тестировать и ещё раз тестировать свои патчи.
В апреле в рамках подготовки патчей для Linux 6.9-rc4 Линус Торвальдс решил бороться с парсерами конфигурационных файлов Kconfig, которые не могут правильно обрабатывать табуляции. Торвальдс написал патч, чтобы намеренно добавить несколько собственных табов в Kconfig, чтобы отбросить любые внешние или сторонние парсеры, которые не могут их правильно обработать. Торвальдс намеренно добавил эти скрытые табы в общий файл Kconfig для обработки размеров страниц ядра. Таким образом, это обязательно приведёт к серьёзным и заметным ошибкам для любых парсеров, не имеющих правильную обработку табов.
В декабре 2023 года Торвальдс рассказал об усталости сопровождающих ядра проекта. По его мнению, сопровождающие ядра Linux должны уметь смотреть на код других людей и обладать возможностью ответить на вопрос: «Это хороший или плохой подход?».
В октябре 2022 года Торвальдс отчитал ментейнеров проекта версии ядра Linux за постоянный срыв дедлайнов и расслабленность в работе. В своём обращении к разработчикам Торвальдс также обратился к тем, кто сдаёт ему проделанную работу после заявленного срока. «Привычку откладывать всё до последнего нужно было оставить в школе. Это совершенно не подходит для разработки ядра Linux», — написал Торвальдс.
