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

[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

[spamsink]

Опоздала идея лет на 30-40, когда дисководы головками медленно двигали. Тогда выигрыш был бы ещё более впечатляющим.

[vak]

Сейчас даже DRAM медленно байтами двигает по сравнению с процессором.

[lev]

double buffering легко делался в ос/ес на ПЛ/1
помнится с приятелем мутили печать с ленты, в один буфер читалось, другой форматировался, третий выводился (без спулера)

[sassa_nf]

How so?

Slow disk => perf is dominated by io wait, you can ignore context switch + buffer copying cost.

[spamsink]

When multiple I/O requests are sent to the driver, the driver would order them according to the current position of the head and the locations of the blocks of the file, minimizing io wait.

[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]

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

[chabapok]

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

Хм.

Наверное, это хорошо с точки зрения снижения энергопотребления, дипломатически выражаясь.

Но опять же - я не пробовал этот механизм. Это вот такое суждение навскидку. Может я и ерунду написал.

ап: кстати вот, есть же задачи, где высокая отзывчивость не на первом месте, и ей можно пожертвовать в ущерб производительности. Я таких задач вобщем-то не встречал, но они бывают.

[ichthuss]

Не обязательно ждать. Несколько собітий могут и так накопиться за то время, пока мі обрабатівали предідущий возврат из системного візова. В єтом случае мі получаем несколько собітий за один системній візов и с нулевой латентностью.

[chabapok]

> Несколько собітий могут и так накопиться за то время, пока мі обрабатівали предідущий возврат из системного візова

там эта очередь - многопоточная, что ли? Один поток уже обрабатывает возврат, а другой поток все еще может в эту очередь что-то добавить. А потом хоба - и уже в какой-то момент считатется, что возврат произошел, и события больше не добавляются в эту очередь. Например таким моментом может быть обращение к size(). Ну то есть, начало работы с элементами.

Ну, вприницпе, да. Полезно.

[ichthuss]

Не уверен, что понял ваш комментарий. Суть именно в том, чтобі в одном треде обрабатівать много одновременніх операций (которіе традиционно бі обрабатівались в разніх тредах). Т.е., условно говоря, возможен подобная последовательность собітий:
- мі имеем сокеті к 100к клиентов. сабмитим 100к запросов на чтение одним сисколлом, ждем ответа
- получаем ответ, обрабатіваем запрос клиента, формируем ответ, сабмитим респонз
- за время, пока мі обрабатівали, пришло еще 10 запросов от клиента, они сразу нам доступні для обработки, уже лежать в кольцевом буфере - пока мі обрабатівали запрос в юзерспейсе, ядро тоже времени не теряло
- мі последовательно обрабатіваем єти запросі, за єто время заканчивается обработка отправки нашего респонза первому клиенту, и єто собітие тоже попадает в буфер
- когда очередь доходит до обработки собітия завершения передачи респонза, мі в ответ опять сабмитим запрос на чтение из єтого сокета.

Ну и т.д. Я не уверен, что ві именно єто имели ввиду под "многопоточной очередью".

[chabapok]

нет, я не єто имел в виду.

для начала мне уже ясно: надо либо читать документацию - либо мы говорим, что пофантазируем как оно могло бы работать правильно. Сейчас мы занимаемся вторым. Надо это понимать.

> за время, пока мі обрабатівали, пришло еще 10 запросов от клиента, они сразу нам доступні для обработки,

а вот єто без многопотока невозможно. То есть тут есть всего 2 варианта: либо мы делаем некий вызов, возвращающий новые события. И тогда єто 1 поток. Либо же мы таких вызовов не делаем, а наша входящая очередь многопоточная, и читатель в ней один (мы), а все писатели в ядре и их много (сокеты, клики мышкой и тд).

> Суть именно в том, чтобі в одном треде обрабатівать много одновременніх операций

а чем это принципиально от epoll отличается? В epoll ты сделал вызов - а тебе возвращается список сокетов, по которым есть обновление (данные для чтения, или появившаяся возможность записать еще если это tcp).

Кстати. Когда сетевая карточка генерирует прерывание, то по умолчанию оно приходит на любое ядро. (можно настроить, запретив какое-то ядро - но нужно ли?) Соответственно, получается задача, что данные из нескольких потоков надо свести в один. Зачем так сделано, я не очень понимаю. Как показала практика, не всегда с первого раза архитектуры делают удачно. С другой же стороны, те кто это делал, явно знали больше, чем я. Тут я затрудняюсь дать оценку. Наверное в каких-то случаях это хорошо, а в каких-то других нет.

[chabapok]

ой, опечатка: "и ей можно пожертвовать в ущерб производительности" -> "и ей можно пожертвовать за счет увеличения производительности"

[ichthuss]

Интересно, как именно єта штука дружит с многопоточностью. Обрабатівать данніе в одном вісокопроизводительном треде - єто, разумеется, круто, но может біть недостаточно.

[sassa_nf]

The whole idea is that you are going to have more fds than threads.

Eg 10M sockets >> 32 CPU_count.

[ichthuss]

Єто понятно. Речь о том, что в приводиміх примерах описано, как обрабатівать, скажем, 1М сокетов в одном треде, но не о том, как обрабатівать 16М сокетов в 16 тредах на 16 ядрах. Как именно предлагается єто реализовать? Один ринг-буфер на все треді с безблокировочнім извлечением єлемента? По одному ринг-буферу на каждій тред (и как тогда решается проблема длинной обработки одного возврата, из-за которой застопорится обработка всех дескрипторов, віпавших на єтот тред)? Что-то промежуточное?

[sassa_nf]

That's left as exercise to the reader.

If you used epoll, you'll notice that io_uring is not that different. The user of the API needs to figure out how to share work, how to associate execution context with IO requests and how to manage system-wide progress.

For example, if it is a Async framework, the execution context is a Future or a Promise of the IO result.

Spreading work among threads can be via hashing and periodic rehashing, work stealing, etc, really task-specific. But if you are able to saturate CPU without that, then you can shrug it off as unnecessary.

[dedekha]

Все это очень хорошо и действительно решает проблемы однако очень быстро ведет к сложным fsm. A по моим ненаучным но долгосрочным наблюдениям сложные fsm недоступны среднему программисту. Интересно может ли помочь ИИ?

[vak]

Да, сложность интерфейса маленько превышает способности гуманоида. 😀
Народ пытается упростить на Rust, но пока не впечатляет.

https://github.com/tokio-rs/io-uring

На Си++ ещё кривее выходит.

https://live.boost.org/doc/libs/1_87_0/doc/html/boost_asio/reference/io_context.html

Может совсем какой другой язык программирования нужен при таком подходе.

[dedekha]

Дело в аппликации. Никто не сможет справиться матрицей 1000x1000 state/event если у большинства проблемы с 10x10.

https://www.google.com/search?q=state+explosion+problem&oq=state+expl&gs_lcrp=EgRlZGdlKgcIAhAAGIAEMgYIABBFGDkyBwgBEAAYgAQyBwgCEAAYgAQyBwgDEAAYgAQyBwgEEAAYgAQyBwgFEAAYgAQyBwgGEAAYgAQyBwgHEAAYgAQyBwgIEAAYgATSAQg5NDkzajBqMagCALACAQ&sourceid=chrome&ie=UTF-8

[ichthuss]

В общем-то, теоретически ничто не мешает компилятору преобразовать код, написанній как для тредов, в код, написанній для асинка. Просто одна длинная процедура разбивается на куски-колбєки. Другое дело, подходят ли для єтого распространенніе язіки. Вроде бі концептуально Єрланг для чего-то подобного создавался, может, подойдет, но не уверен - сам не пробовал.

[dedekha]

В синхроном коде можно иметь 1000 кусков типа: послать сообщение, ждать ответа, обработать ответ (*).

При прямом конвертировании в асинхронный код каждый такой кусок добавляет один state и один event к общей матрице.

(*) Простота и наглядность такого кода одна из главных причин почему люди мучаются с много-поточностью.

[sassa_nf]

epoll done right, and support for arbitrary fd, not just network sockets.