Kernel Recipes 2026 — FlexiGuard против Time Slice Extension: обработка блокировок

Современное оборудование масштабируется за счет добавления ядер, но накладные расходы на синхронизацию все больше ограничивают масштабируемость в пользовательском пространстве. Блокирующие блокировки надежны, но приводят к высоким затратам на передачу управления из-за частых переключений контекста. Спин-блокировки, напротив, минимизируют задержку при передаче управления, но их производительность резко падает при переподписке (т.е., когда потоков больше, чем аппаратных контекстов), поскольку потоки, находящиеся в режиме ожидания, вытесняют держателей блокировок в контекстах, допускающих вытеснение. В попытке получить лучшее из обоих миров многие приложения, ориентированные на производительность, по-прежнему полагаются на спин-блокировки с последующей парковкой (например, мьютексы POSIX). Однако, как и другие блокировки, балансирующие между спин-блокировкой и блокировкой, спин-блокировки с последующей парковкой основаны на произвольных эвристиках, которые часто приводят к неоптимальной производительности. FlexGuard (SOSP’25) — это неэвристический метод синхронизации, использующий eBPF для мониторинга переключений контекста и обнаружения вытеснений в критической секции. Когда блокировка прерывается, FlexGuard заблаговременно переводит ожидающие потоки из состояния ожидания в состояние блокировки, освобождая ресурсы ЦП для быстрого возобновления прерванной критической секции. Реагируя на фактические события выполнения, а не на статические пороговые значения, FlexGuard может повысить производительность до 6 раз по сравнению с мьютексами POSIX. Другой подход, часто обсуждаемый в сообществе Linux (и используемый в Solaris), направлен на полное предотвращение прерываний со стороны держателей блокировок путем расширения временных интервалов планировщика. Недавние предложения Linux, включая патч Томаса Глейкснера (2025), используют rseq для эффективного уведомления ядра о том, что поток удерживает блокировку. Вместо прерывания такого потока планировщик позволяет ему работать до тех пор, пока блокировка не будет снята, сохраняя прогресс. Расширение временных интервалов давно является предметом дискуссий среди разработчиков. Чтобы лучше понять, следует ли интегрировать расширения временных срезов в ядро ​​Linux, мы оцениваем обе методики на микротестах и ​​в различных приложениях, включая оптимизированный для памяти индекс базы данных LevelDB, Dedup от PARSEC, а также Raytrace и Streamcluster от SPLASH2X. Наши результаты показывают, что оба подхода решают разные проблемы и дополняют друг друга, а не заменяют, обеспечивая преимущества как в условиях перегрузки, так и без нее. Виктор ЛАФОРЕ