В ветку Linux 7.4, объединенную 22 октября 2026 года, вошла критически важная оптимизация подсистемы workqueue. Разработчик Tejun Heo изменил логику сброса очередей: теперь система проверяет только те очереди, которые использовались с момента последнего сброса, а не перебирает все возможные CPU. Это решение решает проблему масштабирования на высокопроизводительных серверах с большим количеством ядер, таких как Intel Xeon и AMD EPYC.
Суть проблемы и решение
Ранее при сбросе workqueue (например, при принудительной записи логов в файловую систему XFS) ядро тратило время на обход очереди для каждого возможного процессорного ядра, даже если они были простаивать. Инженер Huawei Яо Кай (Yao Kai) выявил, что на 128-ядерной машине этот процесс занимал до 64 микросекунд на один сброс, что создавало узкое место при интенсивной работе с журналами транзакций (CIL).
Результаты бенчмарков
Оптимизация радикально меняет метрики производительности на многопроцессорных системах. Ниже приведены конкретные цифры ускорения для 192-ядерной двухузловой машины:
| Сценарий | Было (операций/сек) | Стало (операций/сек) | Ускорение |
|---|---|---|---|
| Idle per-cpu workqueue | 40 000 | 4 200 000 | ~105x |
| Idle unbound workqueue | 450 000 | 4 300 000 | ~9.5x |
| 16 потоков (per-cpu) | 30 000 | 110 000 | ~3.6x |
| 16 потоков (unbound) | 60 000 | 180 000 | 3x |
Важно отметить, что плотные сценарии, где активно используются все очереди, не замедлились (per-cpu) или замедлились лишь на 15–20% (unbound), при этом путь добавления задач в очередь (queue path) остался неизменным.
Почему это важно
Для корпоративных серверов и систем с высокой плотностью вычислений экономия десятков микросекунд на каждом вызове сброса лога суммируется в значительное снижение задержек и повышение пропускной способности. Оптимизация особенно актуальна для файловых систем, таких как XFS, которые часто сталкиваются с необходимостью принудительного сброса журналов.
Источник: Phoronix ↗