Admin
Администратор
150 микросекунд против 12 — новое поколение Xeon медленнее предыдущего. Почему серверные процессоры Intel стали проблемой для realtime-систем.
Предлагаемая защита снижает tcp_lat с 151 до примерно 30 мкс, без заметной потери по питанию.
У современных серверных Intel Xeon появилась неприятная особенность: иногда процессор «просыпается» заметно дольше, чем ожидают приложения с жёсткими требованиями к задержкам. В некоторых конфигурациях Linux это выливается в сотни микросекунд паузы, и для сетевых и торговых систем, телеком-нагрузок, realtime-планировщиков и других чувствительных сценариев такая мелочь превращается в вполне ощутимый тормоз. Сейчас в рассылке разработчиков ядра обсуждают небольшой патч, который должен заметно снизить эту задержку на Xeon поколения Sapphire Rapids и новее.
Проблема проявляется, когда используется энергосберегающий алгоритм выбора состояний простоя (menu governor) вместе с конфигурацией NOHZ_FULL, где ядро старается максимально «усыплять» тики таймера на отдельных CPU для снижения шума и джиттера. Инженер облачной инфраструктуры Ионуц Некита из Wind River обратил внимание, что на серверных платформах Intel 2022+ такой режим может приводить к «чрезмерно глубокому» уходу в пакетные C-состояния, из которых выход обходится слишком дорого по времени. В результате средняя задержка пробуждения на Sapphire Rapids и даже на более свежих Granite Rapids может достигать примерно 150 мкс, тогда как на предыдущих поколениях Xeon уровня Ice Lake и Skylake речь шла о 12–21 мкс.
Причина, по сути, не в каком-то одном «сломанном месте», а в том, что у современных серверов выросла цена выхода из глубокого сна. На это накладываются накладные расходы управления питанием DDR5, более сложная схема питания и отключения отдельных «плиток» (tiles) в новых Xeon, восстановление CXL-ссылок и другие особенности актуальных платформ. В такой среде слишком оптимистичный выбор глубокого состояния простоя легко превращает кратковременный простой в заметно долгий выход обратно в работу.
Предложение выглядит удивительно простым: добавить в прогноз простоя 25-процентный запас, чтобы алгоритм реже выбирал «слишком глубокие» состояния, когда пауза на самом деле короткая. Идея в том, что при уже остановленном тике и небольшом прогнозируемом простое исходная логика опирается на время до следующего таймера слишком напрямую, и на платформах с дорогим выходом из C-состояний это оказывается чрезмерно консервативным решением. Новый подход вводит страховку в прогнозе, но при этом всё равно ограничивает расчёт сверху тем же временем до следующего события, чтобы не скатиться в постоянный выбор слишком мелкого сна и не потерять энергоэффективность.
По словам автора, тесты на Sapphire Rapids с qperf (tcp_lat) показывают заметный эффект: средняя задержка снижается примерно со 151 мкс до порядка 30 мкс, то есть примерно в пять раз. На платформах с быстрыми переходами в C-состояния существенных побочных эффектов не увидели: на Ice Lake задержка осталась около 12 мкс, на Skylake около 21 мкс. Отдельно отмечается, что по измерениям энергопотребления разница укладывается в менее чем 1% по мощности пакета в смешанных нагрузках, то есть в пределах шумов измерений.
Сам патч небольшой, около 16 строк, и фактически меняет одну строку кода, остальное это поясняющие комментарии. Сейчас изменение отправлено на обсуждение в рассылку разработчиков ядра Linux, и дальше будет зависеть от результатов ревью и дополнительного тестирования, в том числе на более новых Xeon, где эффект, вероятно, должен сохраниться, но цифр по ним в первой отправке пока не приводят.
