[lttng-dev] [MODULES RFC PATCH] Add PID field to block_* events

[Julien Desfossez]

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" <jdesfossez at efficios.com>
>>> To: "mathieu desnoyers" <mathieu.desnoyers at efficios.com>
>>> Cc: lttng-dev at lists.lttng.org, "Julien Desfossez"
>>> <jdesfossez at efficios.com>
>>> 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