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.