Re: [PATCH] virtio-blk: Add stats VQ to collect information about devices

[Sasha Levin <levinsasha928@gmail.com>]

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.

How can this be used? my vision behind it was automation of kernel
testing and benchmarking.

I created a simple set of scripts that does bisection of kernel issues
(which is a combination of 'git bisect run' scripts and a simple
framework that generates /sbin/init used for testing without having to
touch any guests or images.

The scripts builds a simple image which contains only whats required to
test the kernel, and runs the test kernel and test image to determine
whether we hit a 'git bisect good' or 'git bisect bad' automatically.

I was looking to expand it to allow detection of more than just patches
that break things, but also patches that caused a performance hit in a
specific scenario.

-- 

Sasha.