Асинхронный линукс

[vak]

Народ, кто-нибудь уже поимел опыт с <linux/io_uring.h>? Как оно по жизни?

Неожиданно для себя обнаружил, что в Линуксе пять лет назад появилась крутая фича. А именно три системных вызова, реализующих эффективный асинхронный интерфейс ко всем сервисам ядра.

• int io_uring_setup(unsigned entries, struct io_uring_params *p);
• int io_uring_enter(unsigned fd, unsigned to_submit, unsigned min_complete, unsigned flags, sigset_t *sig);
• int io_uring_register(unsigned fd, unsigned opcode, void *arg, unsigned nr_args);

Революционная штука, как я погляжу. Может коренным образом изменить подход к разработке приложений. Только сложновато для программиста выходит. Есть статьи про это дело.

• "io_uring By Example"
• "Welcome to Lord of the io_uring"
• "An Introduction to the io_uring Asynchronous I/O Framework"

Comments

[lev]

отлично, будем выполнять ио в кернеле.
радость хакерам.

[vak]

Где же ещё выполнять ио? Всегда было в кернеле. Только с переключением контекста на каждый системный вызов.

[lev]

я че-то туплю. оно сделано чтобы поллить завершение операции без syscall?

[vak]

Ага.

[lev]

джизус крайст. а async io без поллинга никак? не признают богомерзких threads?

[vak]

Threads никто не отрицает, но сами по себе они не справляются, если темп запросов на порядки превышает скорость переключения контекста.

[lev]

пардон, опять туплю. контекст переключается медленне, чем приходят байты с конечного устройства?

[vak]

Запросов может быть, скажем, 300 тыс/сек, а скорость обработки прерываний 10 тыс/сек. Цифры из реального проекта.

[lev]

интересно, i286 успевал обрабатывать внешний модем на com порту с 56к/сек (там же вроде бы прерывание на байт).

[vak]

Не успевал он. Не зря народ охотился тогда на чипы 16с550 в замену стандартных 16c450 - там имелось FIFO на 16 байт. Темп прерываний уменьшался и компьютер начинал справляться.

[lev]

ok, даже с фифо, если прерывание на половине буфера, это 7к/сек

[vak]

Тогдашние компьютеры справлялись примерно с 10к прерываний в секунду. Но для карточек с большим количеством COM-портов приходилось в драйверах переходить на поллинг вместо прерывания на каждый байт. Я в то время собаку съел на оптимизации драйверов. Весёлое время было.

[lev]

все таки, меня удивляет такое медленное переключение контекста.

[vak]

Ну это медицинский факт по выражению Остапа Бендера. Никуда не денешься. В RTOS удаётся слегка ускорить за счёт уменьшения контекста, но несильно. Мне и в RTOS доводилось переделывать драйверы на поллинг вместо прерываний, чтобы справляться с пиковой нагрузкой. Был такой проект бриджа из Ethernet в HDLC 2 Мбит/сек на микроконтроллере ARM с частотой 40 МГц. Вполне справлялся при 100% загрузке канала, после переделки на поллинг.

[sassa_nf]

It's not just speed of context switch. If you have 10M connections, you just can't have thread-per-connection. So you need ways of processing orders of magnitude more connections than you have threads.

[x86128]

не не, там в юзерспейсе всё. наоборот это безопасней и меньше копирований из пустого в порожнее