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: Ming Lei
Subject: Re: [Qemu-devel] [PATCH v1 00/17] dataplane: optimization and multi virtqueue support
Date: Tue, 5 Aug 2014 18:50:01 +0800

On Tue, Aug 5, 2014 at 5:56 PM, Kevin Wolf <address@hidden> wrote:
> Am 05.08.2014 um 11:50 hat Ming Lei geschrieben:
>> On Tue, Aug 5, 2014 at 5:38 PM, Stefan Hajnoczi <address@hidden> wrote:
>> > On Tue, Aug 05, 2014 at 11:33:01AM +0800, Ming Lei wrote:
>> >> These patches bring up below 4 changes:
>> >>         - introduce object allocation pool and apply it to
>> >>         virtio-blk dataplane for improving its performance
>> >>
>> >>         - introduce selective coroutine bypass mechanism
>> >>         for improving performance of virtio-blk dataplane with
>> >>         raw format image
>> >>
>> >>         - linux-aio changes: fixing for cases of -EAGAIN and partial
>> >>         completion, increase max events to 256, and remove one unuseful
>> >>         fields in 'struct qemu_laiocb'
>> >>
>> >>         - support multi virtqueue for virtio-blk
>> >
>> > Please split up this patch series into separate patch series.
>> >
>> > These are independent changes and there is no reason to combine them.
>> > You're doing yourself a disservice because changes that are ready to be
>> > applied are getting held up by those that still need more discussion.
>>
>> Without previous optimization patches, the mq conversion can't
>> obtain so much improvement, that is why I put them together.
>>
>> Also mq conversion depends on linux-aio fix too.
>>
>> Also it becomes a difficult to test these patches if they are splitted,
>> and describing the dependency is a bit annoying too.
>>
>> > That will also make the performance discussions easier to follow since
>> > each patch series should include performance results, making it easy to
>> > understand how much improvement each change brings.
>>
>> The number can be found inside patches, for example, patch 02 has
>> the number for using obj pool, and patch 09 has the number for
>> bypassing coroutine, and patch 17 has the number for mq conversion.
>
> A claim like "~5%-10% throughput improvement" isn't numbers nor a

Sorry, it is a range from 5% to 10% per my test.

> precise description of your benchmark setup.

And the benchmark setup can be found in the 0/17 commit log,
and it is basically a FIO(randread, libaio, direct io, ...) test running
in VM.

Sorry for not describing them clearly.

Thanks,



reply via email to

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