On 2014-05-21 16:01, Mathieu Desnoyers wrote:
CCing Jens Axboe, who really know better than I do about the block
layer! Also adding Steven, since he maintains the Linux upstream block
layer instrumentation (closely matching the lttng-modules version).
The blktrace parts are still maintained by me, actually not sure why it
moved location.
----- Original Message -----
From: "Julien Desfossez" <[email protected]>
To: "mathieu desnoyers" <[email protected]>
Cc: [email protected], "Julien Desfossez" <[email protected]>
Sent: Wednesday, May 21, 2014 5:29:15 PM
Subject: [MODULES RFC PATCH] Add PID field to block_* events
Most of the block events have the "comm" field, but we have no way to
match a block event to a certain PID which makes performing accurate
per-process analyses difficult.
Color me clueless, but isn't the block I/O activity independent of
the PID which triggers the I/O (e.g. issuing the read(), write(),
(and so on) system calls) for read ahead, writeback kernel thread
activity ? Or perhaps are those just rare special case, and for
the usual case we can use the current PID in which the block layer
tracepoints are hit as indicator of which PID triggered the I/O ?
It's usually only disconnected for the case of async writes. But even
for that case, it's interesting to see who is submitting the IO.
blktrace already issues a pid note, though, for every new process that
does IO. So what problem are we trying to solve here? The case of
multiple threads with the same ->comm?
--
Jens Axboe
_______________________________________________
lttng-dev mailing list
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
