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: Wed, 27 Aug 2014 17:13:38 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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.

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 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.

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.

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.

Best regards

Benoît

> 
> Thanks
> Anshul Makkar
> www.justkernel.com



reply via email to

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