qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] block IO latency tracker without using QMP socket.


From: Benoît Canet
Subject: Re: [Qemu-devel] block IO latency tracker without using QMP socket.
Date: Thu, 28 Aug 2014 17:00:44 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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.

Best regards

Benoît

> 
> Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]