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

[Stefan Hajnoczi]

On Fri, Sep 18, 2020 at 10:59 AM Denis V. Lunev <den@virtuozzo.com> wrote:
> 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.

Thanks!

Stefan