В мире Linux ускорение на 5% — это повод для праздника. Ускорение на 10% — это новость для первых полос. Но недавняя серия патчей для подсистемы io_uring принесла нечто невероятное: рост производительности в 50-80 раз для определенных сценариев.
Самое интересное? 🤔 Это открытие сделал не одинокий хакер, годами изучающий ассемблерный код, а разработчик в диалоге с Claude AI.
Вот история о том, как беседа с нейросетью привела к одной из самых значительных оптимизаций ввода-вывода (I/O) за последние годы.
🛑 Проблема: "Ленивый" режим
io_uring совершил революцию в асинхронном вводе-выводе в Linux. Позволяя отправлять и получать данные без лишних системных вызовов, он дал приложениям возможность выжимать максимум из современных NVMe SSD.
Однако в подсистемах AHCI (SATA) и SCSI оставалась странная аномалия. На топовом железе io_uring летал. Но на системах, которые большую часть времени простаивали (idle) — то есть процессор не был занят другими задачами — скорость однопоточного чтения была на удивление низкой. 📉
Ожидалось, что io_uring будет давать стабильно низкую задержку. Но в режиме простоя ядро словно "засыпало за рулем", слишком долго ожидая завершения операций записи на диск. 😴
🤖 Как AI нашел иголку в стоге сена
Прорыв начался, когда разработчик ядра пытался понять это вялое поведение на контроллерах AHCI. Трассировка (логи работы) сбивала с толку: железо завершало работу быстро, но ядро почему-то не забирало результат мгновенно.
Разработчик обратился за помощью к Claude, предоставив ему стеки вызовов и графы функций io_uring. AI проанализировал поток данных и указал на тонкий логический пробел в том, как ядро выбирает между прерываниями и поллингом (активным опросом) именно в этом состоянии. 💡
Claude заметил, что когда система простаивает, эвристика "оптимистичного спиннинга" (когда процессор крутится в цикле, ожидая результата, вместо того чтобы уйти в сон) работала неправильно для старых драйверов типа AHCI. Ядро решало "уснуть" (ждать прерывания), хотя должно было "активно ждать" (polling), что добавляло огромную задержку к каждой операции.
🛠️ Техническое решение: Принудительный опрос
Исправление коснулось логики опроса в io_uring.
В высоконагруженных сетях и хранилищах поллинг (polling) часто быстрее прерываний (interrupts).
— 🔔 Прерывания: Железо сигналит процессору: "Я всё!". Процессор бросает текущие дела, переключает контекст и обрабатывает сигнал. Это экономит энергию, но убивает латентность.
— ⚡ Поллинг: Процессор в бешеном темпе проверяет статус железа: "Готово? Готово? А сейчас?". Это сжигает 100% ядра, но дает минимальную задержку.
Проблема была в том, что io_uring полагался на блочный слой (block layer), чтобы решить: спать или опрашивать. В патчах, созданных после подсказки AI, логику поправили так, чтобы ядро корректно распознавало состояние "простаиваю, но жду данных" для AHCI/SCSI.
Заставив ядро агрессивно проверять завершение операций, когда ему больше нечем заняться, разработчики практически убрали "задержку пробуждения".
🏁 Результат: В 80 раз быстрее
Бенчмарки (тесты скорости) выглядят просто фантастически.
На тестовой системе с обычным SATA SSD через драйвер AHCI:
— До: ~500 IOPS (операций в секунду) при однопоточном чтении на простаивающей системе.
— После: ~40 000+ IOPS. 🚀
Это ускорение в 80 раз.
Убрав цикл "сон -> ожидание прерывания -> пробуждение" и заменив его на "проверь немедленно", ядро начало использовать простаивающие ресурсы CPU для мгновенной доставки данных. Для баз данных и высокочастотных торговых платформ, работающих на старых интерфейсах, это устраняет гигантское бутылочное горлышко.
🎯 Вывод
Эта оптимизация показывает интересную эволюцию в разработке ядра. Мы больше не просто используем AI, чтобы писать шаблонный код ("напиши мне функцию сортировки"). Мы используем его, чтобы анализировать сложную динамику работы системы, которую человеку трудно визуализировать в голове. 🧠
Ускорение io_uring в 80 раз — это не просто победа для Linux. Это доказательство того, что симбиоз инженера и AI может находить скрытые резервы производительности там, где, казалось бы, всё уже оптимизировано до предела. Возможно, наши операционные системы "спят" на куче других таких открытий, и нам просто нужно правильно спросить. 😉