cgroup IO-Steuerung vs. (die neuen Typen von) Linux AIO

cgroup IO-Steuerung vs. (die neuen Typen von) Linux AIO

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_uringenthä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_FSYNCfunktioniert für normales "gepuffertes IO", es klingt also ziemlich ähnlich wie io_uring).

IOCB_CMD_FSYNCverwendet die Standard-Arbeitswarteschlange des Kernels. io_uringist etwas anders. Jeder io_uringerstellt 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 cgroupinfs/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_WRITEBACKes gesetzt ist.

verwandte Informationen