On 14-05-22 09:50 AM, Jens Axboe wrote: > 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?
Yes, exactly. My original intent was to link the system calls to actual block requests and identify the requests that hit the cache. But since the link between these events is not obvious, I'm thinking of computing a per-thread disk/cache hit ratio. Thanks, Julien _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
