Umgehen in Linux v5.0 einige Arten von asynchroner E/A die Cgroup-E/A-Controller?
EDIT: Die Analyse von gepuffertem Schreiben (write()) und fsync() könnte relativ komplex sein. Ich habe hier einen interessanten Beitrag zur Steuerung gepufferter Schreibvorgänge gefunden:https://andrestc.com/post/cgroups-io/. Wenn Ihnen diese Frage zu komplex erscheint, wäre es vielleicht am einfachsten, zunächst nach gepuffertem Read() mit zu fragen io_uring
.
Die neue AIO-Schnittstelle io_uring
enthält AIO-Äquivalente von read(), write() und auch fsync(). Wenn Sie sie für „gepufferte IO“ (normale zwischenspeicherbare Datei-IO) verwenden und die IO nicht sofort vom Seitencache erfüllt werden kann, wird sie asynchron mithilfe von Arbeitswarteschlangen ausgeführt.
Auch der ursprüngliche AIO-Systemaufruf io_submit()
vor kurzemerhielt Unterstützung fürIOCB_CMD_FSYNC
. Dieser neue Befehl verwendet Workqueues, um vfs_fsync() aufzurufen. (Dave Chinner betont ausdrücklich,IOCB_CMD_FSYNC
funktioniert für normales "gepuffertes IO", es klingt also ziemlich ähnlich wie io_uring
).
IOCB_CMD_FSYNC
verwendet die Standard-Arbeitswarteschlange des Kernels. io_uring
ist etwas anders. Jeder io_uring
erstellt seine eigene parallel verwaltete Arbeitswarteschlange (cmwq).
Ich habe mir auf meinem System angesehen ps -eo pid,user,args,cgroup|grep [[]
. Der einzige Kernel-Thread innerhalb einer Cgroup war zufällig [vhost-nnn]
. Ich habe festgestellt, dass der Kernel diese vhost_worker-Threads explizit in die Cgroup des Benutzerprozesses platziert, der sie erstellt hat. Siehevhost_attach_cgroups_work().
Im Gegensatz dazu gibt es keine Erwähnung von cgroup
infs/io_uring.cnoch inkernel/workqueue.c.
Strukturdateiverweist nicht direkt auf eine bestimmte Kontrollgruppe. Obwohl es auf eineStruktur-Inode, das auf „die zugehörige Cgroup wb“ verweist, sofern CONFIG_CGROUP_WRITEBACK
es gesetzt ist.