Re: QEMU 5.0 virtio-blk performance regression with high queue depths

[Denis V. Lunev]

On 9/17/20 3:41 PM, Stefan Hajnoczi wrote:
> On Wed, Sep 16, 2020 at 5:43 PM Denis V. Lunev <den@virtuozzo.com> wrote:
>> On 9/16/20 5:07 PM, Denis V. Lunev wrote:
>>> I will make a check today.
>>>
>>> Talking about our performance measurements, we have not
>>> seen ANY performance degradation, especially 30-40%.
>>> This looking quite strange to me.
>>>
>>> Though there is quite important difference. We are always
>>> using O_DIRECT and 'native' AIO engine.
>>>
>>> Den
>> I have put my hands into this and it looks like you are right. There is
>> a difference. It is not as significant for me as in your case, but I observe
>> stable around 10% difference with 128 vs 256 queue size.
>>
>> I have checked with:
>> - QEMU 5.1
>> - Fedora 31 in guest
>> - qcow2 (64k, 1Mb) and raw image on host
>> - nocache and both threaded/native IO modes
>>
>> The test was run on Thinkpad Carbon X1 gen 6 laptop.
>>
>> For the reference, I have seen 330k IOPS for read
>> at max which is looking awesome for native and 220k
>> IOPS for threads.
> Thanks for confirming! Reverting the commit is unattractive since it
> does improve performance in some cases.
>
> It would be good to understand the root cause so the regression can be
> fixed without reducing queue-size again.
>
> Do you have time to investigate?
I will make a try next week.

Den