Re: [ANNOUNCE] Native Linux KVM tool v2

[Sasha Levin <levinsasha928@gmail.com>]

On Thu, 2011-06-16 at 17:50 -0500, Anthony Liguori wrote:
> On 06/16/2011 09:48 AM, Pekka Enberg wrote:
> > On Wed, Jun 15, 2011 at 6:53 PM, Pekka Enberg<penberg@kernel.org>  wrote:
> >> - Fast QCOW2 image read-write support beating Qemu in fio benchmarks. See the
> >>   following URL for test result details: https://gist.github.com/1026888
> >
> > It turns out we were benchmarking the wrong guest kernel version for
> > qemu-kvm which is why it performed so much worse. Here's a summary of
> > qemu-kvm beating tools/kvm:
> >
> > https://raw.github.com/gist/1029359/9f9a714ecee64802c08a3455971e410d5029370b/gistfile1.txt
> >
> > I'd ask for a brown paper bag if I wasn't so busy eating my hat at the moment.
> 
> np, it happens.
> 
> Is that still with QEMU with IDE emulation, cache=writethrough, and 
> 128MB of guest memory?
> 
> Does your raw driver support multiple parallel requests?  It doesn't 
> look like it does from how I read the code.  At some point, I'd be happy 
> to help ya'll do some benchmarking against QEMU.
> 

Each virtio-blk device can process requests regardless of other
virtio-blk devices, which means that we can do parallel requests for
devices.

Within each device, we support parallel requests in the sense that we do
vectored IO for each head (which may contain multiple blocks) in the
vring, we don't do multiple heads because when I've tried adding AIO
I've noticed that at most there are 2-3 possible heads - and since it
points to the same device it doesn't really help running them in
parallel.


> It would be very useful to compare as we have some ugly things in QEMU 
> that we've never quite been able to determine how much they affect 
> performance.  Having an alternative implementation to benchmark against 
> would be quite helpful.


-- 

Sasha.