%20Linux%20AIO.png)
No Linux v5.0, alguns tipos de IO assíncronos ignoram os controladores cgroup IO?
EDIT: buffered write() e fsync() podem ser relativamente complexos de analisar. Encontrei uma postagem interessante sobre como controlar gravações em buffer aqui:https://andrestc.com/post/cgroups-io/. Se esta questão parecer muito complexa, talvez seja mais simples começar perguntando sobre read() em buffer com io_uring.
A nova interface AIO io_uringinclui equivalentes AIO de read(), write() e também fsync(). Quando você o usa para "IO em buffer" (IO de arquivo em cache normal) e o IO não pode ser satisfeito imediatamente pelo cache da página, ele é executado de forma assíncrona usando filas de trabalho.
Também a chamada do sistema AIO original io_submit()recentementeganhou apoio paraIOCB_CMD_FSYNC. Este novo comando usa filas de trabalho para chamar vfs_fsync(). (Dave Chinner implica fortementeIOCB_CMD_FSYNCfunciona para "IO em buffer" normal, então soa bastante semelhante a io_uring).
IOCB_CMD_FSYNCusa a fila de trabalho padrão do kernel. io_uringé um pouco diferente. Cada um io_uringcria sua própria fila de trabalho gerenciada por simultaneidade (cmwq).
Eu olhei ps -eo pid,user,args,cgroup|grep [[]no meu sistema. O único thread do kernel dentro de um cgroup era o [vhost-nnn]. Descobri que o kernel coloca explicitamente esses threads vhost_worker dentro do cgroup do processo do usuário que os criou. Vervhost_attach_cgroups_work().
Em contraste, não há menção de cgroup's emfs/io_uring.c, nem emkernel/workqueue.c.
arquivo de estruturanão aponta diretamente para um cgroup específico. Embora aponte para umestrutura inode, que aponta para "o cgroup wb associado" se CONFIG_CGROUP_WRITEBACKestiver definido.