Суть изменений: от косвенных вызовов к инлайнингу
В рамках pull-запросов для Linux 7.3, объединенных разработчиком Майклом Ларабелом, была завершена конвертация фреймворка IOmap в итераторную модель. Ключевое изменение — переход к единому колбэку iomap_next(). Это позволяет компилятору заменять дорогие косвенные вызовы (indirect calls) на прямые и инлайнимые, что критически важно для снижения накладных расходов при обработке метаданных.
Результаты бенчмарков: NVMe Gen5 и малые блоки
Оптимизация особенно заметна на современных накопителях PCIe Gen5 NVMe, где ранее доминировал оверхед при случайных чтениях размером 4K. В тестовой нагрузке io_uring poll mode (одиночное ядро) производительность через файловые системы выросла с 1.92M IOPS до 2.19M IOPS по сравнению с прямым доступом к блочному устройству.
| Параметр теста | EXT4/XFS (до) | EXT4/XFS (после) | Прирост |
|---|---|---|---|
| io_uring poll mode (depth 256) | ~1.92M IOPS | ~2.19M IOPS | до 10% |
| io_uring (общий) | — | — | ~5% |
| libaio (queue depth >= 64) | — | — | ~4% |
Поддержка широкого спектра файловых систем
Хотя метрики приведены для EXT4 и XFS, обновление IOmap интегрировано в ядро для множества других файловых систем. Это включает Btrfs, EXT2, EROFS, F2FS, GFS2, HPFS, FUSE, exFAT, ZoneFS, NTFS и NTFS3. Изменения затрагивают базовый слой VFS, что обеспечивает синхронное улучшение производительности ввода-вывода для всей экосистемы Linux.
Почему это важно
Для серверных инфраструктур и высоконагруженных приложений, использующих io_uring для асинхронного I/O, каждое снижение задержки на уровне ядра имеет значение. Устранение узкого места в __iomap_dio_rw() позволяет файловым системам эффективнее использовать пропускную способность современных NVMe-накопителей, сокращая разрыв между производительностью «сырого» устройства и логической файловой системой.
Источник: Phoronix ↗