%20Linux%20AIO.png)
En Linux v5.0, ¿algunos tipos de E/S asíncronas omiten los controladores IO de cgroup?
EDITAR: la escritura almacenada en búfer () y fsync () pueden ser relativamente complejas de analizar. Encontré una publicación interesante sobre el control de escrituras almacenadas aquí:https://andrestc.com/post/cgroups-io/. Si esta pregunta parece demasiado compleja, quizás sería más sencillo comenzar preguntando sobre la lectura almacenada en búfer() con io_uring.
La nueva interfaz AIO io_uringincluye equivalentes AIO de read(), write() y también fsync(). Cuando lo usa para "IO en búfer" (IO de archivo en caché normal) y el caché de página no puede satisfacer el IO inmediatamente, se ejecuta de forma asincrónica usando colas de trabajo.
También la llamada original del sistema AIO io_submit()recientemente.obtuvo apoyo paraIOCB_CMD_FSYNC. Este nuevo comando utiliza colas de trabajo para llamar a vfs_fsync(). (Dave Chinner implica fuertementeIOCB_CMD_FSYNCfunciona para "IO en búfer" normal, por lo que suena bastante similar a io_uring).
IOCB_CMD_FSYNCutiliza la cola de trabajo predeterminada del kernel. io_uringes ligeramente diferente. Cada uno io_uringcrea su propia cola de trabajo administrada de forma simultánea (cmwq).
Miré ps -eo pid,user,args,cgroup|grep [[]en mi sistema. El único hilo del núcleo dentro de un cgroup resultó ser [vhost-nnn]. Descubrí que el kernel coloca explícitamente estos subprocesos vhost_worker dentro del cgroup del proceso de usuario que los creó. Vervhost_attach_cgroups_work().
Por el contrario, no se menciona cgroup's enfs/io_uring.c, ni ennúcleo/cola de trabajo.c.
archivo de estructurano apunta directamente a un cgroup específico. Aunque apunta a unainodo de estructura, que apunta al "wb del cgroup asociado" si CONFIG_CGROUP_WRITEBACKestá configurado.