Benoît Canet <benoit.ca...@irqsave.net> writes: > The Thursday 28 Aug 2014 à 13:36:35 (+0100), Stefan Hajnoczi wrote : >> On Wed, Aug 27, 2014 at 04:58:12PM +0200, Anshul Makkar wrote: >> > 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). >> > >> > 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. >> > >> > Can't use "info blockstats" QMP command as qmp socket is used and blocked >> > by some other process in our subsystem. >> > >> > 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. >> >> Simplest option: use iostat(1) inside the guest. >> >> Or you can use tracing tools to measure block I/O request latency. >> >> An example from a few years ago: >> http://www.linux-kvm.org/page/Virtio/Block/Latency >> >> It depends what you are trying to achieve. > > Stefan: ProfitBrick is a cloud provider. > > This means they could prepare AMI (Virtual machine images) with stuff in it > but > they never would access the shell of a running VM. > > What happen in the guest after the AMI instanciation into a running VM is the > end user business and the cloud provider should not violate the end > user territory. > > I also agree that having QEMU collecting latencies statistics would be > very useful.
For what it's worth, query-blockstats already reports the sum of certain latencies.
