Async IO in Linux

Maurog

случайно сегодня натолкнулся на статью
http://davmac.org/davpage/linux/async-io.html
возможно, кому-то интересно будет почитать

vall

многа бакав а про нормальный ядерный aio ни слова =)

sergey_m

Там написано что его в Linux нет пока (точнее был в 2.5). Это правда?

vall

О! я и не заметил что статья НАСТОЛЬКО свежая

conv3rsje

Там написано что его в Linux нет пока (точнее был в 2.5).

Вроде есть. Насколько хорошо работает сказать не могу, но выглядит нормально и вполне живой.
glibc'овый posix aio действительно сделан через треды, но в libaio есть что-то типа совместимости с ним.

sergey_m

Не совсем понял. Нужно делать LD_PRELOAD=libaio чтобы заработал ядерный?

conv3rsje

Прелоад вроде там не прокатывает, ибо структуры имеют разный размер (aiocb и iocb).
У libaio (не стоит смущаться lib в названии) какой-то свой интерфейс с шахматами и балеринами.

Marinavo_0507

А зачем нужно aio именно не через треды?

conv3rsje

А зачем оно нужно через треды?
Есть же в керныле aio, почему бы его не заюзать - там по крайней мере можно надеяться на какой-никакой интеллект

Marinavo_0507

А зачем оно нужно через треды?

ну известное мне приложение, где оно надо (не обязательно через треды) - squid например - я в своё время сам добавлял многопроцессный aio, мне не нравилось что там разработчики делали
ну и наверное любые многопользовательские штуки, где есть что-то типа базы данных

там по крайней мере можно надеяться на какой-никакой интеллект

неестественный интеллект - ядро же не знает особенности твоего приложения

conv3rsje

неестественный интеллект - ядро же не знает особенности твоего приложения

Зато оно знает особенности системы хранения. И может что-нибудь с чем-нибудь сгруппировать (я надеюсь).
Да и вообще, без тредов живется легче, так что если есть возможность обойтись без них - почему бы и нет?
К тому же в libaio есть забавный механизм оповещения о завершении через eventfd, то есть можно поллить aio вместе с обычными.

Marinavo_0507

К тому же в libaio есть забавный механизм оповещения о завершении через eventfd, то есть можно поллить aio вместе с обычными.

Мне как теоретику эти штуки не нравятся тем, что асинхронного page in всё равно нет. То есть вот ты ждёшь, а страницу под тобой отмапят в это время, и жди теперь синхронно, надо делать mlockall или переносить в ядро всю функциональность, а не только планировщик ввода/вывода.

Зато оно знает особенности системы хранения. И может что-нибудь с чем-нибудь сгруппировать (я надеюсь).

Ну если из процессов/тредов идут запросы, то всё это остаётся в силе.

conv3rsje

То есть вот ты ждёшь, а страницу под тобой отмапят в это время, и жди теперь синхронно, надо делать mlockall или переносить в ядро всю функциональность, а не только планировщик ввода/вывода.

Ничего не понял. Что мешает залочить страницу перед io, разлочить по завершению операции?

Ну если из процессов/тредов идут запросы, то всё это остаётся в силе.

Остается. Но придется лепить по треду на каждый активный io.

Marinavo_0507

Ничего не понял. Что мешает залочить страницу перед io, разлочить по завершению операции?

Ну в любой момент можно нарваться на page fault теоретически. Если не сделал mlockall. Так что если хочется надёжно совсем обойдить без синхронного чтения, то не получится.

Остается. Но придется лепить по треду на каждый активный io.

Что в этом плохого?

conv3rsje

Так что если хочется надёжно совсем обойдить без синхронного чтения, то не получится.

Можно. Можно тупо засвапиться. Использование aio может просто значительно упростить структуру приложения, а гарантированно избежать page fault - это другая бяда.
Тред на ио - это как-то не круто. Мне вообще ссыкотно тредами пользоваться, тем более если их много.
ЗЫ Чо та я заговариваюсь, пойду спать.

Marinavo_0507

Мне вообще ссыкотно тредами пользоваться, тем более если их много.

Процессами можно ещё, если именно общее адресное пространство смущает.
Ну насколько много? 100 - это не много например. 10k - вроде многовато, но ядру не ссыкотно скармливать столько операций за раз? Хз в каком порядке оно их сделает, учитывая, что оно не знает, что для тебя важнее. Обычно же создают разумное количество воркеров и между ними разбрасывают.

Dasar

10k - вроде многовато, но ядру не ссыкотно скармливать столько операций за раз? Хз в каком порядке оно их сделает, учитывая, что оно не знает, что для тебя важнее.

можно взять такую крайность:
есть, например, storage с высокой латентностью и с высокой пропускной способностью (например, с доступом - пересылка флешек голубиной почтой)
также есть миллион пользователей, которые хотят с этого storage-а читать
в теории, эффективнее будет, если ядру скормить весь миллион операций - чем устраивать какие-то очереди у себя

Marinavo_0507

миллион голубей одновременно выпустить - всё в фекалиях потонет

Dasar

миллион голубей одновременно выпустить - всё в фекалиях потонет

а если голубь один - большой, толстый и флэшка у него эксабайтная?

Marinavo_0507

ну он улетит выполнять первый запрос
а через пару секунд придёт ещё миллион запросов, и все ждут

Marinavo_0507

когда тестируют производительность ввода/вывода в операциях в секунду, то при глубине очереди > несколько десятков запросов, производительность уже не растёт с ростом глубины
то есть больше сотни ядру нет смысла скармливать в обычных условиях (необычные условия - какая-нибудь нестандартная аппаратная конфигурация)

Dasar

а через пару секунд придёт ещё миллион запросов, и все ждут

зато следующим запросом уйдет весь миллион, а так будет за каждый раз спрашиваться только по величине пула

Dasar

то при глубине очереди > несколько десятков запросов, производительность уже не растёт с ростом глубины

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

Marinavo_0507

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