From: Kevin Wolf <kwolf@redhat.com>
To: Roman Penyaev <roman.penyaev@profitbricks.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Fam Zheng <famz@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH V2 1/1] linux-aio: prevent submitting more than MAX_EVENTS
Date: Wed, 13 Jul 2016 13:45:20 +0200 [thread overview]
Message-ID: <20160713114520.GC5548@noname.redhat.com> (raw)
In-Reply-To: <CAJrWOzC1a=SYz=4Qbbbck9rHhMFXoxbsriTSqJTsYACqoVNtbw@mail.gmail.com>
Am 13.07.2016 um 13:33 hat Roman Penyaev geschrieben:
> Just to be sure that we are on the same page:
>
> 1. We have this commit "linux-aio: Cancel BH if not needed" which
>
> a) introduces performance regression on my fio workloads on the
> following config: "iothread=1, VCPU=8, MQ=8". Performance
> dropped from 1878MB/s to 1606MB/s with Stefan's fix, that is
> ~14%.
Do we already understand why the performance regresses with the patch?
As long as we don't, everything we do is just guesswork.
Kevin
> b) reproduces IO hang, because of in-flights > MAX_EVENTS.
>
> So probably this commit should be reverted because of a) not b).
>
> 2. Stefan has fix for 1.b) issue repeating io_getevents(), which
> is obviously an excess for generic cases where MQ=1 (queue depth
> for virtio_blk is also set to 128 i.e. equal to MAX_EVENTS on
> QEMU side).
>
> 3. The current patch also aims to fix 1.b) issue restricting number
> of in-flights.
>
>
> Reverting 1. will fix all the problems, without any need to apply
> 2. or 3. The most lazy variant.
>
> Restricting in-flights is also a step forward, since submitting
> till -EAGAIN is also possible, but leads (as we already know) to
> IO hang on specific loads and conditions.
>
> But 2. and 3. are mutual exclusive and should not be applied
> together.
>
> So we have several alternatives and a choice what to follow.
>
> --
> Roman
next prev parent reply other threads:[~2016-07-13 11:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 17:51 [Qemu-devel] [PATCH 1/1] linux-aio: prevent submitting more than MAX_EVENTS Roman Pen
2016-07-13 2:23 ` Fam Zheng
2016-07-13 7:57 ` [Qemu-devel] [PATCH V2 " Roman Pen
2016-07-13 10:31 ` Paolo Bonzini
2016-07-13 11:33 ` Roman Penyaev
2016-07-13 11:45 ` Kevin Wolf [this message]
2016-07-13 14:53 ` Roman Penyaev
2016-07-15 9:18 ` Roman Penyaev
2016-07-15 9:58 ` Paolo Bonzini
2016-07-15 10:17 ` Roman Penyaev
2016-07-15 10:37 ` Paolo Bonzini
2016-07-15 11:35 ` Roman Penyaev
2016-07-15 12:57 ` Paolo Bonzini
2016-07-15 15:03 ` Roman Penyaev
2016-07-13 12:22 ` Eric Blake
2016-07-13 12:57 ` Roman Penyaev
2016-07-14 12:18 ` Stefan Hajnoczi
2016-07-13 7:43 ` [Qemu-devel] [PATCH " Paolo Bonzini
2016-07-13 7:50 ` Roman Penyaev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160713114520.GC5548@noname.redhat.com \
--to=kwolf@redhat.com \
--cc=famz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=roman.penyaev@profitbricks.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).