Разработчики ядра Linux рассматривают новый механизм — «steal governor» (регулятор steal time). Он призван улучшить производительность, когда несколько виртуальных машин соперничают за ограниченные физические ресурсы процессора. Предложение использует долю steal time CPU, наблюдаемую внутри гостевой системы, чтобы динамически изменять набор виртуальных CPU, которые планировщик гостевой ОС считает предпочтительными для выполнения обычных задач.
Функция в первую очередь ориентирована на сильно виртуализированные серверы, где администраторы намеренно выделяют больше виртуальных процессоров, чем физически может одновременно исполнять общий пул CPU. При высокой нагрузке такая переподписка приводит к более частому вытеснению vCPU, задержкам из-за блокировок, дополнительным накладным расходам планирования и, в итоге, к снижению общей пропускной способности.
Последняя версия патчей (11) была опубликована 25 августа 2026 года. Разработчик предложил рассмотреть её для sched/core в цикле разработки Linux 7.3 с возможным включением в Linux 7.4. Это пока только предложение: функция находится на стадии ревью и не входит в стабильное ядро Linux.
Что такое CPU steal time?
CPU steal time — понятие, специфичное для виртуализации.
Представьте виртуальную машину с восемью vCPU. Изнутри ВМ операционная система ведёт себя так, будто эти восемь процессоров доступны. Однако виртуальные CPU в конечном счёте должны выполняться на физических процессорах хоста.
Если несколько ВМ конкурируют за один и тот же пул физических ресурсов, гипервизор может временно вытеснять vCPU одной ВМ, чтобы предоставить физический CPU другой.
Steal time — это время CPU, которое гостевая ОС учитывает как недоступное ей из-за работы виртуализационного слоя.
Высокое значение steal time обычно является надёжным признаком того, что виртуальная машина конкурирует за физические процессорные ресурсы.
Проблема «шумного соседа»
Steal governor в первую очередь решает то, что инженеры по виртуализации обычно называют проблемой шумного соседа (noisy neighbor problem).
Рассмотрим упрощённый пример. Три ВМ имеют по 32 vCPU каждая, а общий доступный им пул составляет 64 логических CPU. Такая конфигурация может работать нормально, пока ВМ не заняты одновременно. Если все три внезапно оказываются под высокой нагрузкой, они могут суммарно требовать больше процессорного времени, чем физическая машина способна предоставить. Гипервизору приходится чаще вытеснять одни vCPU и предоставлять физические CPU другим.
Такие вытеснения особенно проблематичны, если vCPU был остановлен в момент выполнения критической секции или удержания блокировки. Другие потоки могут продолжать ждать, пока нужный vCPU снова получит возможность выполняться. Результат бывает парадоксальным: выделение ВМ большего числа виртуальных CPU иногда способно снизить её эффективность при высокой конкуренции за физический CPU.
Linux может реагировать автоматически
Администраторы уже могут мониторить steal time и вручную корректировать конфигурации ВМ. Новый governor в Linux пытается автоматизировать часть этого процесса.
Предлагаемый драйвер steal_governor периодически измеряет системный steal time внутри гостевой системы. На основе этих измерений он корректирует новый набор планировщика, введённый серией патчей, — preferred CPUs. Эти CPU физически не удаляются из ВМ и не переводятся в offline-состояние.
Вместо этого Linux при высокой конкуренции рассматривает меньшее подмножество активных vCPU как предпочтительные процессоры для выполнения обычных задач. Планировщик старается консолидировать нагрузку на эти CPU, оставляя остальные доступными, но менее предпочтительными.
В текущей реализации механизм ориентирован прежде всего на задачи класса FAIR/CFS. Поддержка других классов планирования, включая RT и sched_ext, пока не является частью предлагаемого решения.
Как работает steal governor
Базовая политика намеренно проста. По умолчанию governor проверяет steal time каждые 1000 миллисекунд, то есть раз в секунду. Два порога определяют дальнейшие действия. Если steal time поднимается выше значения по умолчанию 5%, governor уменьшает набор предпочтительных CPU на одно ядро. Если steal time падает до 2% или ниже, он добавляет одно ядро обратно в предпочтительный набор.
Процесс повторяется постепенно. В упрощённом виде: высокая конкуренция — использовать меньше preferred CPUs; низкая конкуренция — постепенно восстанавливать preferred CPUs.
Governor всегда оставляет как минимум одно ядро предпочтительным и не позволяет предпочтительному набору превышать активный набор CPU виртуальной машины.
Preferred CPUs — ключевой элемент
Другая важная часть предложения — введение нового элемента планировщика под названием preferred CPUs. Linux уже поддерживает маски CPU, описывающие онлайн- и активные процессоры. Предлагаемые патчи добавляют дополнительную маску cpu_preferred_mask, которая всегда является подмножеством активной маски CPU.
Когда steal governor не используется, набор предпочтительных CPU совпадает с активным набором. При росте конкуренции governor может сжимать предпочтительный набор. Планировщик затем старается концентрировать обычные задачи на этих предпочтительных CPU. Предлагаемая реализация затрагивает несколько решений планировщика, включая обработку пробуждений задач, периодические тики и балансировку нагрузки.
Linux фактически не отключает остальные CPU
Это важный нюанс. Governor не делает hot-unplug vCPU при появлении конкуренции. vCPU остаются активными и доступными системе. Governor лишь даёт планировщику информацию о том, какие CPU предпочтительнее использовать для обычных задач.
Такой подход позволяет избежать части сложностей, связанных с динамическим удалением и последующим восстановлением CPU. Список предпочтительных CPU также доступен через:
/sys/devices/system/cpu/preferred
Этот интерфейс sysfs предназначен только для чтения и позволяет увидеть, какие CPU ядро в данный момент считает предпочтительными.
Привязка к CPU (affinity) по-прежнему соблюдается
Ядро также не будет переопределять явные настройки привязки к CPU. Если администратор или приложение разрешает задаче выполняться только на CPU, который steal governor считает непредпочтительным, Linux продолжит соблюдать эту конфигурацию affinity.
Это важно для корпоративных нагрузок, где администраторы намеренно закрепляют определённые процессы за конкретными CPU. Preferred CPUs действуют как политика планировщика, а не как абсолютное ограничение.
Прямое взаимодействие между ВМ не требуется
Одна из интересных сторон решения — виртуальным машинам не нужно напрямую общаться друг с другом. У каждой гостевой системы собственный steal time. Когда конкуренция растёт, каждая участвующая ВМ независимо замечает увеличение steal time и начинает консолидировать свою нагрузку на меньшем числе предпочтительных CPU. Когда конкуренция снижается, ВМ постепенно снова расширяет предпочтительный набор.
По сути, steal time становится косвенным сигналом, который предоставляет виртуализационный слой. Это позволяет нескольким гостевым системам реагировать на изменение нагрузки без специального протокола взаимодействия между ними.
Лучше всего работает, когда все ВМ участвуют
Есть важное ограничение. Подход работает лучше всего, когда все конкурирующие ВМ включают эту функцию. Если одна гостевая система игнорирует steal time, а её соседи добровольно уменьшают количество preferred CPUs, не участвующая ВМ потенциально может продолжить использовать более широкий набор CPU и получить преимущество в распределении вычислительных ресурсов.
Поэтому разработчик рекомендует рассматривать governor как механизм, который целесообразно включать согласованно на ВМ, разделяющих один и тот же пул физических CPU.
Параметр CONFIG_STEAL_GOVERNOR предлагается собирать как модуль. Это позволяет не включать механизм автоматически и при необходимости управлять его загрузкой и параметрами.
Ранние бенчмарки показывают большой прирост на некоторых нагрузках
Самая интересная часть предложения — ранние данные о производительности. Тестирование проводилось в средах виртуализации PowerPC, x86 и s390.
В одном из PowerPC-тестов две ВМ работали с общим ограниченным пулом физических CPU и запускали конкурирующие нагрузки Hackbench. По мере роста количества групп Hackbench преимущества governor увеличивались.
Заявленные улучшения суммарной производительности двух ВМ составляли примерно:
10,6% при 10 группах Hackbench;
37,8% при 20 группах;
44,3% при 40 группах.
Эти цифры не следует интерпретировать как универсальное улучшение производительности Linux или как ускорение каждой отдельной ВМ на 44%.
Это результаты конкретного виртуализированного теста, в котором измерялась суммарная производительность двух ВМ при намеренно созданной конкуренции за CPU.
Тем не менее результаты показывают, почему снижение конкуренции между vCPU иногда может значительно увеличить общую пропускную способность.
Некоторые нагрузки могут немного замедлиться
Разработчик также признаёт важный компромисс.
Для нагрузок, которым просто нужно как можно больше доступного процессорного времени, при включённом governor возможны небольшие регрессии.
Это логично, потому что governor намеренно старается концентрировать работу на меньшем числе preferred CPUs.
Этот подход наиболее полезен в ситуациях, когда вытеснение vCPU создаёт дополнительные издержки, выходящие за рамки простой потери времени выполнения на CPU.
Потенциально выиграть могут нагрузки, для которых характерны:
интенсивное использование блокировок;
критические секции;
чувствительность к состоянию CPU-кэшей;
чувствительность к TLB;
большое количество синхронизации;
смешанный OLTP- и OLAP-профиль.
Для таких приложений снижение дорогостоящих задержек из-за вытеснения vCPU может перевесить издержки от выполнения работы на меньшем числе предпочтительных процессоров.
При этом эффект зависит от конкретной нагрузки. Для простых CPU-bound задач дополнительная консолидация может не дать преимуществ и даже привести к небольшой регрессии.
Базы данных могут стать важным сценарием использования
Серверы баз данных специально рассматриваются как один из потенциально интересных сценариев.
Современные СУБД часто сочетают большое число потоков, механизмы синхронизации, операции с интенсивным использованием памяти и транзакции, чувствительные к задержкам.
Если гипервизор вытесняет vCPU в момент, когда он выполняет критически важную часть работы, другие потоки базы данных могут продолжать ждать результат.
Консолидация нагрузки на меньшее число vCPU потенциально способна уменьшить количество подобных ситуаций и повысить общую пропускную способность, даже несмотря на то, что планировщик намеренно использует меньшее число предпочтительных виртуальных процессоров.
Однако это пока следует рассматривать как потенциальный сценарий использования, а не как гарантированное преимущество для всех СУБД.
Разработка всё ещё продолжается
Серия патчей прошла множество ревизий. Версия 8 появилась в июле, версия 10 — в августе, а последняя версия 11 была опубликована 25 августа.
В последней версии разработчик считает механизм достаточно проработанным для того, чтобы рассмотреть вопрос о включении в sched/core, однако дополнительное тестирование по-прежнему необходимо.
Разработка подобных изменений планировщика обычно проходит через несколько циклов ревью и тестирования, поскольку даже относительно небольшое изменение политики планирования может повлиять на производительность большого количества разных нагрузок, архитектур процессоров и платформ виртуализации.
Не в Linux 7.2
Хотя серия появилась вскоре после релиза Linux 7.2, её не следует путать с функцией этого релиза. Это всё ещё предлагаемая серия патчей для ядра.
В последней версии разработчик Shrikanth Hegde попросил мейнтейнеров планировщика рассмотреть серию для sched/core в цикле разработки Linux 7.3, с возможным целевым включением в Linux 7.4.
Этот срок не гарантирован. Мейнтейнеры ядра могут запросить дополнительные ревизии, тестирование или архитектурные изменения перед принятием.
Почему steal governor важен
Переподписка CPU — фундаментальная часть современной виртуализации.
Облачные провайдеры и корпоративные дата-центры редко готовы мириться с тем, что физические процессоры простаивали только потому, что каждой ВМ выделено достаточно теоретической ёмкости CPU для обработки её максимальной возможной нагрузки.
Переподписка CPU позволяет операторам инфраструктуры достигать более высокой загрузки физических ресурсов. Компромисс проявляется, когда многие ВМ оказываются загружены одновременно.
Steal governor предлагает интересное решение: вместо того чтобы требовать от гипервизора или администратора постоянно изменять выделение CPU, сама гостевая система Linux реагирует на конкуренцию, добровольно концентрируя свою нагрузку на меньшем числе vCPU. При этом остальные vCPU не отключаются — они просто становятся менее предпочтительными целями для обычных задач.
Заключение
Предлагаемый в Linux steal governor использует необычный подход к улучшению поведения виртуальных машин: когда физические CPU перегружены, гостевая система добровольно пытается консолидировать работу на меньшем числе своих vCPU.
Отслеживая steal time и динамически корректируя новую маску preferred CPUs, Linux может концентрировать нагрузку при высокой конкуренции и постепенно расширять предпочтительный набор, когда доступно больше процессорных ресурсов.
Ранние тесты показывают, что стратегия может давать существенный прирост суммарной пропускной способности для некоторых сильно конкурирующих нагрузок. При этом простые CPU-bound задачи могут получить меньшую выгоду или даже небольшую регрессию.
Функция ещё не включена в основную ветку Linux. Последняя версия 11 предлагается для рассмотрения в sched/core, а Linux 7.4 указан разработчиком как возможная цель. Если серия в итоге попадёт upstream, steal governor может дать виртуальным машинам Linux новый способ автоматически адаптироваться к одной из устойчивых проблем сильно консолидированных серверов: слишком много виртуальных CPU конкурируют за слишком мало физических вычислительных ресурсов.
