On Fri, Jun 17, 2011 at 2:03 AM, Sasha Levin <levinsasha928@xxxxxxxxx> wrote: > 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. One thing that QEMU does but I'm a little suspicious of is request merging. virtio-blk will submit those 2-3 heads using bdrv_aio_multiwrite() if they become available in the same virtqueue notify. The requests will be merged if possible. My feeling is that we should already have merged requests coming through virtio-blk and there should be no need to do any merging - which could be a workaround for a poor virtio-blk vring configuration that prevented the guest from sending large requests. However, this feature did yield performance improvements with qcow2 image files when it was introduced, so that would be interesting to look at. Are you enabling indirect descriptors on the virtio-blk vring? That should allow more requests to be made available because you don't run out of vring descriptors so easily. Stefan -- 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
