Серия правок планировщика sched: Flatten the pick вошла в ядро Linux 7.3 – о слиянии стало известно 2026 года. Очередь выполнения EEVDF стала одноуровневой: иерархия контрольных групп сохранена для учёта нагрузки, но следующая задача выбирается из плоского списка. Изменение задумано против рывков кадров под фоновой нагрузкой – той самой ситуации, когда игра делит процессор со сборкой, браузером и системными службами. Вместе с плоским выбором появился переключатель cgroup_mode с четырьмя способами распределения веса между группами, и значением по умолчанию стал concur. В приложенном к серии тесте на связке Core i7-2600K и Radeon RX 580 минимальная частота кадров поднялась с 4 до 29 FPS, но сравнивались там не старое и новое ядро, а две настройки кванта времени.
Почему вес контрольной группы дробится между ядрами
Планирование по контрольным группам в описании к серии названо давней болью ядра: сложности начинаются с распределения веса и заканчиваются иерархическим выбором задачи. Суммарный вес группы делится между всеми процессорами системы по глобальной дроби, и уже на 64 логических процессорах доля каждого сводится к весу одной задачи с приоритетом nice 19. Системы на 256 процессоров давно перестали быть редкостью, и там доля ещё меньше.
Контрольная группа (cgroup) – механизм ядра Linux, который объединяет процессы в группы и распределяет между ними процессорное время, память и другие ресурсы. В настольных системах в отдельные группы попадают, в частности, пользовательские сеансы и службы systemd.
Привычный обходной путь – умножать вес группы на число процессоров. Он ломается, когда вся нагрузка группы концентрируется на одном ядре: вес легко выходит за пределы, соответствующие nice -20, а вычисления упираются в ограничения разрядности. Из-за этого верхний предел суммарного веса группы приходится держать искусственно низким, что давно раздражало пользователей.
Единая очередь вместо иерархического выбора
Иерархия контрольных групп в новой схеме остаётся на месте вместе с промежуточными операциями постановки в очередь и снятия с неё, но сама очередь EEVDF вынесена наружу. Все готовые к выполнению задачи оказываются на одном уровне, и промежуточные узлы больше не заслоняют собой готовность отдельных процессов – именно они и порождали задержки, на которые жаловались чаще всего. Приближение shares_weight при этом сохраняется полностью, то есть привычное соотношение долей между группами не меняется.
EEVDF (Earliest Eligible Virtual Deadline First) – основной планировщик задач в Linux, пришедший на смену CFS. Он выбирает из задач, которым система ещё должна процессорное время, ту, у которой ближе виртуальный срок выполнения.
Плата за плоский список – постоянный пересчёт эффективного веса. Он выполняется при постановке задачи в очередь, при выборе следующей задачи и по тику таймера. Постановка и снятие по-прежнему пропорциональны глубине иерархии, зато сам выбор стал одноуровневым, а логика вытеснения заметно упростилась.
Четыре режима cgroup_mode и смена значения по умолчанию
Способ распределения веса переключается параметром cgroup_mode в отладочном интерфейсе планировщика. Доступны варианты up, max, concur и tasks. По умолчанию теперь работает concur – самый точный и одновременно самый затратный: он добавляет счётчик задач в группе и утяжеляет обновление усреднённой нагрузки.
Смена умолчания объясняется подготовкой к плоской очереди, где иерархический вес значит куда больше прежнего, поэтому мелкие доли веса групп понадобилось убрать. В описании правки прямо сказано, что перемена кому-то помешает: часть администраторов успела приспособиться и вручную завышала вес там, где это допускалось. Параметр остаётся настраиваемым именно на такой случай.
Что показал тест на Core i7-2600K с Radeon RX 580
Проверку проводили на конфигурации, которую в самой серии назвали «картошкой»: Core i7-2600K поколения Sandy Bridge и Radeon RX 580 на архитектуре Polaris. Игра Shadows: Awakening из магазина GOG запускалась через Lutris с GE-Proton10-34 и Steam Runtime 3 (sniper); в разрешении 1080p на такой системе она обычно идёт ровно. Чтобы создать нагрузку, параллельно запускались восемь копий скрипта, полностью занимающего процессорное время, – по одной на каждый логический процессор. С таким фоном игра, по описанию автора серии, становилась почти неиграбельной. Показания снимал MangoHud.
Затем игра перезапускалась с укороченным квантом времени – одной десятой от базового значения. На опубликованной диаграмме приведён и сам префикс команды запуска:
chrt -o --sched-runtime 100000 0
Квант времени (slice) – отрезок процессорного времени, который планировщик отдаёт задаче до следующего пересмотра очереди. Чем он короче, тем раньше наступает виртуальный срок задачи и тем чаще она возвращается на процессор, но тем выше и накладные расходы на переключения.
| Показатель | Стандартный квант | Укороченный квант |
|---|---|---|
| Минимальный FPS | 4,0 | 29,0 |
| Средний FPS | 47,5 | 59,2 |
| Максимальный FPS | 83,7 | 83,7 |
| Минимальное время кадра, мс | 9,3 | 10,2 |
| Среднее время кадра, мс | 34,0 | 17,0 |
| Максимальное время кадра, мс | 121,2 | 30,0 |
Средняя частота кадров выросла примерно на четверть, среднее время кадра сократилось вдвое, максимальное – вчетверо. Для плавности важнее всего последняя строка: самый долгий кадр укоротился со 121,2 до 30,0 мс, то есть заметные рывки исчезли. При этом верхняя граница частоты кадров не сдвинулась вовсе, а минимальное время кадра стало чуть хуже: 10,2 мс против 9,3 мс.
Почему цифры теста не равны выигрышу от перехода на Linux 7.3
Обе колонки сняты на одном и том же ядре с уже применёнными правками. В сопроводительном письме отдельно оговорено, что с ядром без плоской очереди результат не сравнивали: задача была прогнать нетривиальную нагрузку и посмотреть, как ведёт себя изменение кванта. Значит, семикратный рост минимального FPS описывает эффект укороченного кванта под искусственной нагрузкой в восемь потоков, а не прибавку, которую даст сам переход на Linux 7.3.
Разброс между прогонами тоже заметен. В майской редакции серии те же измерения дали 3,8 против 20,6 FPS по минимуму и 48,0 против 57,2 по среднему, а максимум тогда не удержался и просел с 87,4 до 80,3 FPS. Один прогон игры с ручным замером через MangoHud остаётся иллюстрацией, а не воспроизводимым бенчмарком.
От RFC в марте до слияния в августе
Первая редакция серии с пометкой RFC появилась в списке рассылки , вторая – , третья – . К правки лежали в ветке sched/core дерева tip, а в основную ветку попали уже в окне слияния Linux 7.3, которое открылось после выхода Linux 7.2 .
Вместе с плоским выбором в планировщик 7.3 приняли и другие изменения: снижение задержки для задач с коротким квантом, исправление кластерного балансирования на гибридных процессорах Intel и предпочтение полностью свободных ядер при балансировке в режиме NOHZ. Разбор всего набора опубликован на Phoronix.
Первый кандидат в выпуски ожидается , стабильный Linux 7.3 – во второй половине октября. Раньше остальных правки достанутся тем, кто собирает ядро из основной ветки: в проекте CachyOS сообщили, что перенесут изменения к себе, но сроков не назвали.
Заключение
При плоском выборе задачи промежуточные уровни иерархии перестают мешать планировщику видеть, кто из процессов действительно готов работать, а в режиме concur вес между контрольными группами распределяется точнее. Выигрыш заметнее там, где под нагрузкой конкурируют десятки процессов из разных групп: фоновая сборка, браузер с десятком вкладок и запущенная игра одновременно. Проверять эффект придётся на своей конфигурации – единственное опубликованное измерение снято на одной машине и показывает влияние кванта времени, а не самих правок. Владельцам старых систем разумнее дождаться независимых замеров на готовом Linux 7.3, а не на ветке разработки.