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@xxxxxxxxxx> 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. -- 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
