Наистина ли няма асинхронен блок I/O на Linux?

(2020) Ако използвате 5.1 или по-нова версия на ядрото на Linux, можете да използвате io_uring интерфейс за подобен на файл I/O и да получите отлична асинхронна работа.

В сравнение със съществуващия интерфейс libaio/KAIO, io_uring има следните предимства:

• Запазва асинхронно поведение при извършване на буфериран I/O (а не само при извършване на директен I/O)
• По-лесен за използване (особено при използване на liburing помощна библиотека)
• По желание може да работи по анкетиран начин (но ще ви трябват по-високи привилегии, за да активирате този режим)
• По-малко режийни разходи за счетоводно пространство за I/O
• По-ниски разходи за процесора поради по-малко превключвания на режима на системно извикване на потребителско пространство/ядро (голяма работа в наши дни поради въздействие на смекчаване на призрак/стопяване)
• Файловите дескриптори и буфери могат да бъдат предварително регистрирани, за да се спести време за картографиране/декартиране
• По-бързо (може да постигне по-висока обща производителност, I/O имат по-ниска латентност)
• Свързаният режим може да изразява зависимости между I/O (›=5.3 ядро)
• Може да работи с I/O, базиран на сокет (recvmsg()/sendmsg() се поддържат от ›=5.3, вижте съобщенията, в които се споменава думата поддръжка в git история на io_uring.c)
• Поддържа опит за анулиране на I/O в опашка (›=5.5)
• Може да поиска I/O винаги да се извършва от асинхронен контекст, вместо по подразбиране да се връща само към punting I/O към асинхронен контекст, когато вграденият път на подаване задейства блокиране (›=5.6 ядро)
• Нарастваща поддръжка за извършване на асинхронни операции след read/ write (напр. fsync (›=5,1), fallocate (›=5,6), splice (›=5,7) и повече)
• По-висок импулс на развитие
• Не блокира всеки път, когато звездите не са идеално подравнени

В сравнение с POSIX AIO на glibc, io_uring има следните предимства:

• Много по-бързо и по-ефективно (по-ниските режийни ползи от горе се прилагат още повече тук)
• Интерфейсът се поддържа от ядрото и НЕ използва пул от нишки в потребителското пространство
• По-малко копия на данните се правят, когато се прави буфериран I/O
• Без борба със сигнали
• POSIX AIO на Glibc не може да има повече от един I /O в полет на един файлов дескриптор, докато io_uring със сигурност може!

Документът Efficient IO with io_uring разглежда много повече подробности относно предимствата и употребата на io_uring. Документът Какво е новото с io_uring описва нови функции, добавени към io_uring от създаването му, докато Бързият растеж на io_uring LWN статия описва кои функции са налични във всяко от ядрата 5.1 - 5.5 с поглед напред към това, което щеше да бъде в 5.6 (вижте също списъка на LWN със статии за io_uring). Има и По-бързо IO чрез io_uring видео презентация (слайдове) от края на 2019 г. от io_uring автор Jens Axboe. И накрая, урокът Lord of the io_uring дава въведение в използването на io_uring.

io_uring общността може да бъде достигната чрез пощенския списък на io_uring и Архивите на пощенските списъци на io_uring показват дневен трафик в началото на 2021 г.

Повторна поддръжка на частичен I/O в смисъла на recv() срещу read(): корекция влезе в ядрото 5.3, което ще автоматично повторете io_uring кратки четения и допълнителен ангажимент влезе в ядрото 5.4, което променя поведението на автоматично се грижи само за кратки четения, когато работи с обикновени файлове по заявки, които не са задали флага REQ_F_NOWAIT (изглежда, че можете да поискате REQ_F_NOWAIT чрез IOCB_NOWAIT или като отворите файла с O_NONBLOCK). По този начин можете да получите recv() стил - кратко I/O поведение от io_uring също.

Софтуер/проекти, използващи io_uring

Въпреки че интерфейсът е млад (първото му въплъщение пристигна през май 2019 г.), някои софтуери с отворен код използват io_uring в дивата природа:

• fio (който също е автор на Jens Axboe) има io_uring ioengine бекенд (всъщност беше въведен още във fio-3.13 от февруари 2019 г.!). Презентацията на SNIA за подобрена производителност при съхранение с помощта на новия I/O интерфейс на ядрото на Linux (слайдове) от двама инженери на Intel заявява те успяха да получат двойно IOPS при едно работно натоварване и по-малко от половината от средната латентност при дълбочина на опашката от 1 при друго работно натоварване, когато сравняват io_uring ioengine с libaio ioengine на устройство Optane.
• Проектът SPDK добави поддръжка за използване на io_uring (!) за блокиране на достъпа на устройства в своята v19. 04 версия (но очевидно това не е бекендът, за който обикновено бихте използвали SPDK, освен за сравнителен анализ). Съвсем наскоро те също изглежда са добавили поддръжка за използването му със сокети във v20.04 ...
• Ceph ангажира io_uring бекенд през декември 2019 г., който беше част от неговата версия 15.1.0. Авторът на ангажимента публикува коментар в github, показващ някои io_uring бекенд има някои победи и загуби спрямо libaio бекенд (по отношение на IOPS, честотна лента и латентност) в зависимост от натоварването.
• RocksDB ангажира io_uring бекенд за MultiRead през декември 2019 г. и беше част от неговия версия 6.7.3. Йенс заявява, че io_uring е помогнало драстично да се намали латентността.
• libev пусна 4.31 с първоначален io_uring бекенд през декември 2019 г. Докато някои от оригиналните точки на автора бяха адресирани в по-нови ядра към момента на писане (средата на 2021 г.) Авторът на libev има някои избрани думи относно зрелостта на io_uring и възприема изчаквателен подход, преди да приложи допълнителни подобрения.
• QEMU ангажира io_uring бекенд през януари 2020 г. и беше част от изданието QEMU 5.0. В io_uring в QEMU: високоефективен диск IO за Linux PDF презентация Юлия Суворова показва io_uring бекенда, превъзхождащ threads и aio бекенда при едно работно натоварване от произволни 16K блокове.
• Samba обедини io_uring VFS бекенд през февруари 2020 г. и беше част от Версия на Samba 4.12. В Linux io_uring VFS backend. Нишката на пощенския списък на Samba , Стефан Мецмахер (авторът на комита) казва, че модулът io_uring е успял да увеличи с около 19% повече пропускателна способност (в сравнение с някои неуточнени бекенд) в синтетичен тест. Можете също да прочетете Async VFS Future PDF презентация от Стефан за част от мотивацията зад промените.
• Експерименталният C++ libunifex на Facebook го използва (но вие също ще имате нужда от 5.6+ ядро)
• Хората от ръжда са писали опаковки, за да направят io_uring по-достъпен за чиста ръжда. rio е една библиотека, за която се говори малко и авторът казва, че те постигна по-висока производителност в сравнение с използването на синхронизиращи повиквания, обвити в нишки. Авторът направи презентация за своята база данни и библиотека на FOSDEM 2020, която включваше възхваляващ раздел добродетелите на io_uring.
• rust библиотека glommio използва изключително io_uring. Авторът (Glauber Costa) публикува документ, наречен Модерното хранилище е много бързо. API-тата са лоши, показвайки, че с внимателна настройка glommio може да получи над 2,5 пъти по-висока производителност спрямо обикновените (неio_uring) системни извиквания при извършване на последователен I/O на устройство Optane.
• Gluster обедини io_uring posix xlator през октомври 2020 г. и беше част от Версия на Gluster 9.0. Авторът на ангажимента споменава, че производителността не е по-лоша от обикновените pwrite/pread системни извиквания.

Проучване на софтуер с помощта на io_uring

• Разработчикът на PostgreSQL Андрес Фройнд е една от движещите сили зад подобренията на io_uring (напр. заобиколно решение за намаляване на конкуренцията за inode на файловата система). Има презентация Асинхронна IO за PostgreSQL (имайте предвид, че видеото не работи до 5-та минута) (PDF), мотивиращ необходимостта от промени в PostgreSQL и демонстриращ някои експериментални резултати. Той изрази надежда да получи незадължителната си поддръжка за io_uring в PostgreSQL 14 и изглежда ясно осъзнава какво работи и не работи дори до нивото на ядрото. През декември 2020 г. Андрес допълнително обсъжда неговата PostgreSQL io_uring работа< /a> в Blocking I/O, async I/O and io_uring pgsql-hackers нишката на пощенския списък и споменава текущата работа може да се види в https://github.com/anarazel/postgres/дърво/aio .
• Проектът Netty има репо за инкубатор, работещо върху io_uring поддръжка, което се нуждае от 5.9 ядро
• libuv има заявка за изтегляне срещу добавянето на io_uring поддръжка, но напредъкът в проекта е бавен
• SwiftNIO добави io_uring поддръжка за събития (но не и системни повиквания) през април 2020 г. и < href="https://github.com/apple/swift-nio/issues/1831" rel="noreferrer">Linux: full io_uring I/O проблем очертава планове за по-нататъшното му интегриране
• Проектът Tokio Rust разработи доказателство за концепцията tokio-uring

Поддръжка на разпространение на Linux за io_uring

• (Края на 2020 г.) Най-новото ядро ​​за активиране на HWE на Ubuntu 18.04 е 5.4, така че могат да се използват io_uring системни повиквания. Тази дистрибуция не пакетира предварително помощната библиотека liburing, но можете да я изградите за себе си.
• Първоначалното ядро ​​на Ubuntu 20.04 е 5.4, така че могат да се използват io_uring системни извиквания. Както по-горе, дистрибуцията не пакетира предварително liburing.
• Първоначалното ядро ​​на Fedora 32 е 5.6 и има пакетиран liburing, така че io_uring може да се използва.
• SLES 15 SP2 има 5.3 ядро, така че могат да се използват io_uring системни извиквания. Тази дистрибуция не пакетира предварително помощната библиотека liburing, но можете да я изградите сами.
• (Средата на 2021 г.) Ядрото по подразбиране на RHEL 8 не поддържа io_uring (предишна версия на този отговор погрешно каза, че поддържа). Според статията за базата знания на Red Hat за добавяне на поддръжка за io_uring (съдържанието е зад стена за плащане на абонати) обратно пренасяне на io_uring към ядрото RHEL 8 по подразбиране се изпълнява.

Надяваме се, че io_uring ще въведе по-добра асинхронна файлово-подобна I/O история за Linux.

(За да добавите малко достоверност към този отговор, в някакъв момент в миналото Jens Axboe (поддържащ слой на блоковия слой на ядрото на Linux и изобретател на io_uring) помислих, че този отговор може да си струва да гласувам за :-)

Истинският отговор, който беше индиректно посочен от Peter Teoh, се основава на io_setup() и io_submit(). По-конкретно, функциите "aio_", посочени от Питър, са част от емулацията на потребителско ниво на glibc, базирана на нишки, което не е ефективна реализация. Истинският отговор е в:

io_submit(2)
io_setup(2)
io_cancel(2)
io_destroy(2)
io_getevents(2)

Обърнете внимание, че страницата с ръководство, датираща от 2012-08 г., казва, че тази реализация все още не е узряла до точката, в която може да замени емулацията на потребителско пространство glibc:

http://man7.org/linux/man-pages/man7/aio.7.html

тази реализация все още не е узряла до точката, в която POSIX AIO реализация може да бъде напълно реимплементирана с помощта на системните извиквания на ядрото.

И така, според последната документация на ядрото, която мога да намеря, Linux все още няма зрял, базиран на ядрото асинхронен I/O модел. И ако приема, че документираният модел всъщност е зрял, той все още не поддържа частичен I/O в смисъла на recv() срещу read().

Както е обяснено в:

http://code.google.com/p/kernel/wiki/AIOUserGuide

и тук:

http://www.ibm.com/developerworks/library/l-async/

Linux предоставя асинхронен блок I/O на ниво ядро, API, както следва:

aio_read    Request an asynchronous read operation
aio_error   Check the status of an asynchronous request
aio_return  Get the return status of a completed asynchronous request
aio_write   Request an asynchronous operation
aio_suspend Suspend the calling process until one or more asynchronous requests have completed (or failed)
aio_cancel  Cancel an asynchronous I/O request
lio_listio  Initiate a list of I/O operations

И ако попитате кои са потребителите на тези API, това е самото ядро ​​- тук е показано само малко подмножество:

./drivers/net/tun.c (for network tunnelling):
static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,

./drivers/usb/gadget/inode.c:
ep_aio_read(struct kiocb *iocb, const struct iovec *iov,

./net/socket.c (general socket programming):
static ssize_t sock_aio_read(struct kiocb *iocb, const struct iovec *iov,

./mm/filemap.c (mmap of files):
generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov,

./mm/shmem.c:
static ssize_t shmem_file_aio_read(struct kiocb *iocb,

и т.н.

На ниво потребителско пространство също има io_submit() и т.н. API (от glibc), но следната статия предлага алтернатива на използването на glibc:

http://www.fsl.cs.sunysb.edu/~vass/linux-aio.txt

Той директно имплементира API за функции като io_setup() като директно syscall (заобикаляйки зависимостите на glibc), трябва да съществува картографиране на ядрото чрез същия подпис "__NR_io_setup". При търсене на източника на ядрото на:

http://lxr.free-electrons.com/source/include/linux/syscalls.h#L474 (URL адресът е приложим за най-новата версия 3.13) ще бъдете посрещнати с директното внедряване на тези io_*() API в ядрото:

474 asmlinkage long sys_io_setup(unsigned nr_reqs, aio_context_t __user *ctx);
475 asmlinkage long sys_io_destroy(aio_context_t ctx);
476 asmlinkage long sys_io_getevents(aio_context_t ctx_id,
481 asmlinkage long sys_io_submit(aio_context_t, long,
483 asmlinkage long sys_io_cancel(aio_context_t ctx_id, struct iocb __user *iocb,

По-новата версия на glibc трябва да направи използването на "syscall()" за извикване на sys_io_setup() ненужно, но без най-новата версия на glibc, винаги можете сами да направите тези извиквания, ако използвате по-новото ядро ​​с тези възможности на "sys_io_setup ()".

Разбира се, има и друга опция за потребителско пространство за асинхронен I/O (напр. използване на сигнали?):

http://personal.denison.edu/~bressoud/cs375-s13/supplements/linux_altIO.pdf

или може би:

Какво е състоянието на POSIX асинхронен I/O (AIO)?

„io_submit“ и приятелите все още не са налични в glibc (вижте manpages на io_submit), което проверих в моя Ubuntu 14.04, но този API е специфичен за Linux.

Други като libuv, libev и libevent също са асинхронни API:

http://nikhilm.github.io/uvbook/filesystem.html#reading-writing-files

http://software.schmorp.de/pkg/libev.html

http://libevent.org/

Всички тези API имаха за цел да бъдат преносими в BSD, Linux, MacOSX и дори Windows.

По отношение на производителността не съм виждал никакви числа, но подозирам, че libuv може да е най-бързият, поради своята лекота?

https://ghc.haskell.org/trac/ghc/ticket/8400

За мрежовия сокет i/o, когато е "готов", той не блокира. Това означава O_NONBLOCK и „готово“.

За диск i/o имаме posix aio, linux aio, sendfile и приятели.