qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Benoît Canet" <benoit.canet@irqsave.net>
To: Anshul Makkar <anshul.makkar@profitbricks.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] block IO latency tracker without using QMP socket.
Date: Wed, 27 Aug 2014 17:13:38 +0200	[thread overview]
Message-ID: <20140827151338.GL31176@irqsave.net> (raw)
In-Reply-To: <CAM4NYE9j_+KFwXPkYX=yBYHGuPJdBr0VcnXm-LLercObuuNmDQ@mail.gmail.com>

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	other threads:[~2014-08-27 15:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27 14:58 [Qemu-devel] block IO latency tracker without using QMP socket Anshul Makkar
2014-08-27 15:13 ` Benoît Canet [this message]
2014-08-28  8:18   ` Markus Armbruster
2014-08-28 12:36 ` Stefan Hajnoczi
2014-08-28 15:00   ` Benoît Canet
2014-08-28 17:14     ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140827151338.GL31176@irqsave.net \
    --to=benoit.canet@irqsave.net \
    --cc=anshul.makkar@profitbricks.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).