systrace reworking? I/O metrics patch?
Posted Mar 8, 2007 7:58 UTC (Thu) by
AnswerGuy (guest, #1256)
Parent article:
Introducing utrace
Two questions come to mind regarding this.
Could systrace be reworked to use the utrace framework? (Because the
semantics around the example specified that no locks were held and
the process' memory was quiescent at the syscall entry ... prior
to execution). I'd love to see systrace merged into the mainline.
The other question would be if it would be possible to built an I/O
metrics patch around this. For years I've wished that we'd get the
atop I/O metrics (kernel-patch-atopcnt package on Debian) merged.
Often enough, when we see that a system is I/O bound, we want to know
which process(es) is (are) hogging which I/O channel(s). A utrace
approach wouldn't be the same (wouldn't be feasible for an atop like
tool). However, it could be used to selectively check on the I/O
behavior of specific processes ... to perform spot checks and undergo
a process of elimination.
JimD
(
Log in to post comments)
