On 08/18/2011 11:29 AM, Sasha Levin wrote:
On Thu, 2011-08-18 at 08:10 -0700, Avi Kivity wrote:
On 08/17/2011 09:38 PM, Sasha Levin wrote:
On Wed, 2011-08-17 at 16:00 -0700, Avi Kivity wrote:
On 08/16/2011 12:47 PM, Sasha Levin wrote:
> This patch adds support for an optional stats vq that works similary to the
> stats vq provided by virtio-balloon.
>
> The purpose of this change is to allow collection of statistics about working
> virtio-blk devices to easily analyze performance without having to tap into
> the guest.
>
>
Why can't you get the same info from the host? i.e. read sectors?
Some of the stats you can collect from the host, but some you can't.
The ones you can't include all the timing statistics and the internal
queue statistics (read/write merges).
Surely you can time the actual amount of time the I/O takes? It doesn't
account for the virtio round-trip, but does it matter?
Why is the merge count important for the host?
I assumed that the time the request spends in the virtio layer is
(somewhat) significant, specially since that this is something that adds
up over time.
Merge count can be useful for several testing scenarios (I'll describe
the reasoning behind this patch below).
The idea behind providing all of the stats on the stats vq (which is
basically what you see in '/dev/block/[device]/stats') is to give a
consistent snapshot of the state of the device.
What can you do with it?
I was actually planning on submitting another patch that would add
something similar into virtio-net. My plan was to enable collecting
statistics regarding memory, network and disk usage in a simple manner
without accessing guests.
Why not just add an interface that lets you read files from a guest
either via a guest agent (like qemu-ga) or a purpose built PV device?
That would let you access the guest's full sysfs which seems to be quite
a lot more useful long term than adding a bunch of specific interfaces.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
