cgroup IO control против (новых типов) Linux AIO

cgroup IO control против (новых типов) Linux AIO

Обходят ли некоторые типы асинхронного ввода-вывода в Linux v5.0 контроллеры ввода-вывода cgroup?

EDIT: buffered write() и fsync() могут быть относительно сложными для анализа. Я нашел интересный пост об управлении буферизованными записями здесь:https://andrestc.com/post/cgroups-io/. Если этот вопрос кажется слишком сложным, возможно, проще всего будет начать с вопроса о буферизованном read() с io_uring.


Новый интерфейс AIO io_uringвключает эквиваленты AIO read(), write(), а также fsync(). Когда вы используете его для «буферизованного ввода-вывода» (обычный кэшируемый файловый ввод-вывод), и ввод-вывод не может быть немедленно удовлетворен кэшем страниц, он выполняется асинхронно с использованием рабочих очередей.

Также оригинальный системный вызов AIO io_submit()недавнополучил поддержкуIOCB_CMD_FSYNC. Эта новая команда использует рабочие очереди для вызова vfs_fsync(). (Дэйв Чиннер настоятельно рекомендуетIOCB_CMD_FSYNCработает для обычного "буферизованного ввода-вывода", поэтому это звучит очень похоже на io_uring).

IOCB_CMD_FSYNCиспользует рабочую очередь ядра по умолчанию. io_uringнемного отличается. Каждый io_uringсоздает свою собственную управляемую параллелизмом рабочую очередь (cmwq).

Я посмотрел ps -eo pid,user,args,cgroup|grep [[]на своей системе. Единственным потоком ядра внутри cgroup оказался [vhost-nnn]. Я обнаружил, что ядро ​​явно помещает эти потоки vhost_worker внутрь cgroup пользовательского процесса, который их создал. Смотритеvhost_attach_cgroups_work().

Напротив, нет никакого упоминания о cgroup's вфс/io_uring.c, ни вkernel/workqueue.c.

структурный файлне указывает напрямую на определенную cgroup. Хотя он указывает наструктура inode, который указывает на «связанную cgroup wb», если CONFIG_CGROUP_WRITEBACKустановлен.

Связанный контент