On Wed, 2008-07-16 at 10:22 -0400, Alan D. Brunelle wrote: > Martin Peschke wrote: > > Low-level device drivers might have additional data which complements > > blktrace data. For example, zfcp, a SCSI HBA driver, is capable of > > obtaining additional latency information per request from HBAs. Those > > latencies allow to further break down the overall D2C request latency > > provided by blktrace. > > > > We propose an additional trace for blktrace, called "driver data". It is > > a sort of small binary blob, which contains a low-level driver specific > > struct. Blktrace would be able to filter this trace (-a option) and > > include it within its binary output. A small device driver specific tool > > on top of blktrace would then analyze "driver data" traces. > > > > Patch 1/3 makes the blktrace kernel code provide blk_add_driver_data() > > for use by device drivers. > > > > Patch 2/3 adds support for driver data traces to blktrace tools. > > > > Patch 3/3 makes zfcp provide additional request latency and queue > > utilization data through blktrace. > > > > > > Patches are against scsi-misc and blktrace git. > > > > > > Martin > > Hi Martin - > > Have you thought about just using blk_add_trace_msg instead? Hi Alan, good point. Yes, we thought about it. It actually inspired blk_add_drv_data(). blk_add_trace_msg adds information to the textual output of blkparse. There is no point in forwarding it to the binary output. We need the opposite. We want driver data to show up in binary ouput. But there is no point in blkparse trying to generate some ascii message from low-level device driver specific data. Besides this would lead us down the path of parsing textual output for our monitoring tool. This would burn more CPU than a c-program which consumes binary data. Martin -- To unsubscribe from this list: send the line "unsubscribe linux-btrace" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
