В конце 2024 года на просторах GitHub появился проект, который заставил даже самых серьёзных системных программистов улыбнуться: scx_horoscope — планировщик задач для ядра Linux, корректирующий поведение CPU в зависимости от положения планет, фаз Луны и так называемой ретроградности. Автор, Lucas Zampieri, с иронией обыграл давний системный фольклор о зависимости работы систем «от фазы Луны», превратив мем в рабочий код, который действительно загружается в ядро и участвует в распределении процессорного времени. За шутливой обёрткой скрывалась демонстрация куда более важного события — появления в ядре механизма, позволяющего вынести логику планирования из монолитного кода в динамически заменяемую политику. Астрология здесь лишь повод обратить внимание; суть — в том, что экспериментировать с алгоритмами распределения ресурсов теперь можно без месяцев ожидания мержа в upstream и без пересборки ядра.

Почему планировщику так трудно угодить всем

Чтобы понять ценность этого прорыва, стоит вспомнить, с чем сталкивается планировщик при каждом тике таймера. Когда количество готовых к выполнению задач превышает число ядер — а в реальных системах это происходит постоянно — ему необходимо принять три взаимосвязанных решения. Какую именно задачу запустить на свободном ядре, насколько долго ей разрешить работать без вытеснения, и как расставить приоритеты между часто противоречащими целями: минимальными задержками для интерактивных приложений, максимальной пропускной способностью для сборочных серверов, строгой изоляцией между контейнерами и учётом аппаратных особенностей вроде NUMA-топологии.

Исторически каждая попытка улучшить баланс этих целей требовала изменения кода внутри ядра. Патч проходил ревью, ждал включения в следующий релиз, затем распространялся через дистрибутивы — цикл, измеряемый не неделями, а годами. В результате ядро получало универсальный, но компромиссный алгоритм, а специфические сценарии оставались без оптимизации. Планировщик O(1) решал проблемы масштабируемости, но был жёстко закодирован. Completely Fair Scheduler (CFS), появившийся в 2007 году, ввёл концепцию виртуального времени и продержался в ядре более пятнадцати лет, но его универсальность имела цену — постоянный компромисс между интерактивностью и пропускной способностью. Альтернативы вроде BFS от Con Kolivas показали, что специализированные решения возможны, но их судьба подчеркнула главную проблему: без форка ядра (который, да-да, нужно поддерживать силами автора форка!) или убеждения мейнтейнеров по поводу принятия изменений изменить поведение планировщика практически невозможно.

Появление sched_ext: новый класс в ядре 6.12

Эта ситуация изменилась с официальным включением класса планировщиков sched_ext в основную ветку ядра с релизом 6.12 в декабре 2024 года (хотя экспериментальные патчи были доступны ещё в тестовых сборках 6.11, стабильная интеграция произошла именно в 6.12 — об этом свидетельствуют как анонсы релиза, так и официальная документация ядра. Для надёжного развёртывания требуется именно эта версия с включённой опцией CONFIG_SCHED_CLASS_EXT).

Архитектура sched_ext строится на чётком разделении ответственности. Ядро сохраняет за собой критически важные функции: управление состоянием задач, примитивы диспетчеризации в виде очередей (DSQ), механизмы миграции между ядрами и, что особенно важно, систему безопасности. При завершении программы-планировщика, срабатывании комбинации клавиш SysRq-S или обнаружении зависших задач ядро инициирует процедуру abort и возвращает все задачи в стандартный класс SCHED_NORMAL. Логика же принятия решений — классификация задач, расчёт внутреннего ранга и длительности кванта времени — полностью передаётся в руки BPF-программы, загружаемой из пользовательского пространства.

Стоит подчеркнуть границы механизма отката. Он защищает от катастрофических сбоев: зависание политики, аварийное завершение процесса. Но он не спасает от логических ошибок в самой эвристике. Если политика постоянно назначает кванты в одну микросекунду или неправильно классифицирует задачи, система продолжит работать — просто с деградировавшей производительностью. Безопасность здесь обеспечивает отказоустойчивость, а не эффективность алгоритма.

Как устроена диспетчеризация в sched_ext

Чтобы понять, как политика влияет на поведение системы, полезно проследить жизненный цикл задачи. При пробуждении задачи через try_to_wake_up() ядро уведомляет политику через хук enqueue(). Политика анализирует задачу — её паттерны пробуждения, использование ресурсов, принадлежность к группам — и решает, куда её поместить: в глобальную очередь, в локальную очередь конкретного ядра или с каким виртуальным временем для приоритезации.

Когда ядро освобождается, вызывается хук dispatch(). Политика извлекает задачу из очереди и передаёт её ядру через scx_bpf_dispatch(), указывая идентификатор задачи и длительность кванта в наносекундах. При необходимости политика может инициировать миграцию задачи между ядрами через scx_bpf_kick_cpu(), если обнаружит дисбаланс нагрузки или нарушение локальности кэша.

Важный терминологический нюанс: политика оперирует внутренним рангом или скором, который преобразуется в порядок вставки в очередь и длительность кванта. Это не ядерные приоритеты в смысле nice, prio или SCHED_FIFO — последние остаются неизменными и обрабатываются ядром независимо от политики. Очереди диспетчеризации (DSQ) могут работать как в режиме FIFO, так и как приоритетные, но «режим» не переключается флагом. Порядок определяется способом вставки: обычная вставка через scx_bpf_dispatch() даёт FIFO-семантику, а вставка с виртуальным временем через scx_bpf_dispatch_vtime() — приоритетную упорядоченность по значению vtime. Таким образом, политика сама управляет порядком через выбор примитива, а не через конфигурацию очереди.

Что на самом деле делает scx_horoscope

Под астрологическим антуражем проект реализует стандартный для sched_ext паттерн: периодическое обновление внешних данных, классификация задач и коррекция параметров диспетчеризации. Каждые шестьдесят секунд библиотека astro вычисляет геоцентрические положения планет, а для определения ретроградности анализируется знак изменения эклиптической долготы за сутки. Эти числа не обладают физическим воздействием — они лишь служат источником коэффициентов для внутренней логики планировщика.

Задачи классифицируются по объективным признакам: наличие политики реального времени (SCHED_FIFO или SCHED_RR), паттерны пробуждения, характер использования процессора или ввода-вывода, принадлежность к определённым cgroup'ам. Важно отметить, что PID 1 не имеет специального статуса для планировщика — критичность определяется политикой планирования, а не номером процесса.

К базовому кванту времени применяются поправки, вычисленные на основе астрологических данных. В самом README проекта используется термин «астрологический приоритет» со шкалой от ста до тысячи, но это внутренняя метрика политики, а не приоритет ядра. Она преобразуется в множители для длительности кванта: определённые знаки зодиака дают повышающие или понижающие коэффициенты для задач определённого типа, ретроградность планеты приводит к штрафу в пятьдесят процентов к кванту для задач её домена, полнолуние даёт повышающий коэффициент для интерактивных задач. Итоговый квант ограничивается глобальными параметрами min_slice_ns и max_slice_ns. Влияние на поведение системы оказывается исключительно через длительность кванта и порядок выборки из очередей — никаких изменений ядерных приоритетов не происходит.

Автор прямо указывает в документации, что проект создан исключительно для образовательных и развлекательных целей. Астрономические вычисления реальны, планировщик действительно загружается в ядро и работает стабильно, но использование астрологии для принятия решений о распределении CPU-времени научно не обосновано. Это демонстрация архитектурных возможностей sched_ext, а не рекомендация к применению в продакшене.

Другие планировщики на базе sched_ext

scx_horoscope — лишь один из проектов в экосистеме scx. Его ценность в провокационной подаче; другие реализации решают практические задачи без иронии. Планировщик scx_lavd (Latency-Aware Virtual Deadline) фокусируется на интерактивности десктопных систем. Он вычисляет виртуальный дедлайн для каждой задачи на основе паттернов пробуждения и отношения времени ожидания к времени выполнения. В тестах на типичных рабочих станциях он показывает снижение девяносто девятого перцентиля задержек на пятнадцать–тридцать процентов по сравнению с CFS.

Планировщик scx_rusty оптимизирован под многопроцессорные серверы с учётом NUMA-топологии. Он минимизирует миграции задач между сокетами процессоров и балансирует нагрузку с учётом тепловых ограничений, что критично для плотно упакованных серверных стоек. Проект scx_flash экспериментирует с предсказанием поведения задач на основе машинного обучения в пользовательском пространстве, передавая результаты политике через разделяемую память.

Общая черта всех этих проектов — скорость итераций. Раньше проверка гипотезы требовала месяцев разработки патча, прохождения ревью и ожидания следующего LTS-релиза. Теперь разработчик может собрать политику, загрузить её на тестовый сервер, собрать метрики и повторить цикл за часы — без перезагрузки и без ожидания принятия изменений в upstream.

Измерение эффективности и практические сценарии

Эксперименты с планировщиками бессмысленны без измерений. Для анализа поведения sched_ext доступны стандартные инструменты: интерфейс /sys/kernel/sched_ext/ предоставляет базовые метрики вроде количества вызовов dispatch() и статистики миграций; bpftrace позволяет отслеживать события планирования в реальном времени; perf sched анализирует задержки переключения контекста; cyclictest замеряет хвостовые задержки для latency-чувствительных сценариев. Ключевой принцип — оценивать не средние значения, а перцентили. Для интерактивных систем критичны именно хвосты распределения: редкие, но длинные задержки разрушают восприятие отзывчивости даже при хороших средних показателях.

Где может пригодиться гибкость sched_ext сегодня? На выделенных игровых серверах игровая логика часто чувствительна к задержкам: кадр должен обрабатываться за фиксированный интервал. Планировщик может выделять гарантированный квант времени игровому процессу, изолируя его от фоновых задач вроде логирования или резервного копирования. В энергоэффективных встраиваемых системах важно минимизировать переключения частоты ядер; планировщик может группировать задачи на минимальном числе ядер, позволяя остальным уходить в глубокий сон. В мультитенантных облачных средах критична изоляция между клиентами — планировщик может реализовать строгие гарантии пропускной способности на уровне ядра, дополняя ограничения cgroup'ов. Для специализированных рабочих станций, используемых в аудиопродакшене или видеомонтаже, важна предсказуемость: планировщик может резервировать ядра под критичные задачи, минимизируя джиттер.

Ограничения и перспективы

Несмотря на элегантность архитектуры, sched_ext остаётся экспериментальным классом. Каждый вызов dispatch() — это переход между ядром и BPF-программой, и при высокой частоте переключений контекста это может давать измеримый оверхед. Ошибки в логике политики проявляются косвенно — через деградацию производительности, а не через панику ядра, что усложняет отладку. API sched_ext продолжает развиваться, и планировщик, собранный под ядро 6.12, может потребовать адаптации под будущие версии.

Особый нюанс касается завершения планировщика. Для типового сценария запуска через стандартные scx_* бинарники документация ядра прямо указывает: завершение процесса-планировщика инициирует abort и возврат задач в SCHED_NORMAL. Однако при нетипичных сценариях — например, при ручном закреплении BPF-link через bpftool — семантика может отличаться. В подавляющем большинстве случаев откат гарантирован, но разработчик должен понимать условия его срабатывания.

В планах разработчиков — поддержка политик в кольце ноль для снижения накладных расходов, интеграция с аппаратными механизмами вроде thermal sensors и данных о кэш-промахах, стандартизация метрик для упрощения сравнения политик. Главный тренд — постепенное стирание границы между «ядром как монолитом» и «ядром как платформой». Сначала это произошло с сетевым стеком через XDP, затем с трассировкой через eBPF, теперь — с планированием. Ядро становится фреймворком, в котором критически важные примитивы предоставляются централизованно, а политики — децентрализованно.

Заключение

scx_horoscope — удачный пример того, как нестандартная подача может привлечь внимание к существенной архитектурной возможности. Астрология здесь служит лишь метафорой; ценность проекта — в демонстрации того, что политика планирования CPU может быть отделена от ядра, реализована в пользовательском пространстве и заменена без перезагрузки. Это не революция, а эволюция инструментария. Планировщики не перестанут быть сложными — баланс между интерактивностью, пропускной способностью и изоляцией остаётся фундаментальной задачей системного программирования. Но теперь у разработчиков появился инструмент для быстрого прототипирования решений под конкретные сценарии.

Иногда для того, чтобы сообщество заметило важное изменение, достаточно добавить немного иронии — и посмотреть на звёзды. Главное — не путать антураж с сутью: за шуткой стоит серьёзная инженерная работа, открывающая новые возможности для тех, кто готов экспериментировать с архитектурой операционной системы. А фаза Луны, как оказалось, действительно влияет на работу компьютера — но только если вы сами напишете код, который это реализует.

Когда планировщик начал смотреть на звёзды: как scx_horoscope показал будущее гибких планировщиков ядра Linux