Benoît Canet <benoit.ca...@irqsave.net> writes: > The Wednesday 27 Aug 2014 à 16:58:12 (+0200), Anshul Makkar wrote : >> Hi, >> >> I am writing a block IO latency tracker. >> >> As obvious, I am calculating the latency by tracking the interval between >> start of IO and end of IO. >> (firing my latency tracker from function BlockDriverAIOCB *raw_aio_submit() >> raw-posix.c when job is submitted). > > Are you sure that your user want to measure latency in this place. > In fact there is a lot of work done before requests reach raw-posix.c so > the numbers you have may be smaller than the reality.
Yes. Whether the difference is significant I can't say without measuring it. > In QEMU IO statistics are collected near the guest in the block device model > so the statitics are close to what the guest would measure. The I/O stats collecting code needs work, though. >> The latency data per QEMU process will be written to shared memory and then >> another app uses this shared memory to read the data. That's a simple >> architecture. > > Why not simply writting periodically a json report (qemu has code to write > json) > into a char device (pipe, tcp socket etc) QEMU support (Markus's idea) ? > >> >> Can't use "info blockstats" QMP command as qmp socket is used and blocked >> by some other process in our subsystem. > > Libvirt can work as a proxy to passthrough simple QMP commands to QEMU. Thus, libvirt doesn't really "block" its QMP socket. > I think this approach is better than having two different programs > manipulating > separate QMP sockets because only one program really accessing QMP > means coherency > can be enforced. You can have multiple QMP monitors. Manipulating state on a secondary monitor behind the management application's back can get you in trouble, as Benoît said. But if all you do with a secondary monitor is query information, you should be fine. > For example libvirt or the program acting as a proxy could whitelist QMP > methods > that are safe to use and do not risk to confuse libvirt state machine. > (Preventing of modifying QEMU state in libvirt's back) > >> Just want a suggestion whether my approach is correct given the constraint >> that I can't use qmp socket or if any alternative is possible. I think the existing interfaces should suffice to get stats out. If not, generally useful improvements are welcome. One off hacks won't help the next guy with a similar problem.
