qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 00/17] dataplane: optimization and multi virt


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v1 00/17] dataplane: optimization and multi virtqueue support
Date: Wed, 06 Aug 2014 09:45:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

Il 06/08/2014 07:33, Ming Lei ha scritto:
>> > I played a bit with the following, I hope it's not too naive. I couldn't
>> > see a difference with your patches, but at least one reason for this is
>> > probably that my laptop SSD isn't fast enough to make the CPU the
>> > bottleneck. Haven't tried ramdisk yet, that would probably be the next
>> > thing. (I actually wrote the patch up just for some profiling on my own,
>> > not for comparing throughput, but it should be usable for that as well.)
> This might not be good for the test since it is basically a sequential
> read test, which can be optimized a lot by kernel. And I always use
> randread benchmark.

A microbenchmark already exists in tests/test-coroutine.c, and doesn't
really tell us much; it's obvious that coroutines execute more code, the
question is why it affects the iops performance.

The sequential read should be the right workload.  For fio, you want to
get as many iops as possible to QEMU and so you need randread.  But
qemu-img is not run in a guest and if the kernel optimizes sequential
reads then the bypass should have even more benefits because it makes
userspace proportionally more expensive.

In any case, the patches as written have no hope of being accepted.  If
you "invert" the logic from aio->co to co->aio, that would be much
better even if it's tedious.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]