From: Josh Durgin <jdurgin@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>,
Chris Friesen <chris.friesen@windriver.com>
Cc: "Benoît Canet" <benoit.canet@irqsave.net>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Andrey Korolyov" <andrey@xdel.ru>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] is there a limit on the number of in-flight I/O operations?
Date: Thu, 27 Aug 2015 17:31:04 -0700 [thread overview]
Message-ID: <55DFABC8.5040006@redhat.com> (raw)
In-Reply-To: <20150827164952.GE8298@stefanha-thinkpad.redhat.com>
On 08/27/2015 09:49 AM, Stefan Hajnoczi wrote:
> On Mon, Aug 25, 2014 at 03:50:02PM -0600, Chris Friesen wrote:
>> The only limit I see in the whole call chain from
>> virtio_blk_handle_request() on down is the call to
>> bdrv_io_limits_intercept() in bdrv_co_do_writev(). However, that doesn't
>> provide any limit on the absolute number of inflight operations, only on
>> operations/sec. If the ceph server cluster can't keep up with the aggregate
>> load, then the number of inflight operations can still grow indefinitely.
>
> We probably shouldn't rely on QEMU I/O throttling to keep memory usage
> reasonable.
Agreed.
> Instead rbd should be adjusted to support iovecs as you suggested. That
> way no bounce buffers are needed.
Yeah, this is pretty simple to do. Internally librbd has
iovec-equivalents. I'm not sure this is the main source of extra memory
usage
though.
I suspect the main culprit here is rbd cache letting itself burst too
large, rather than the bounce buffers.
Andrey, does this still occur with caching off?
Josh
next prev parent reply other threads:[~2015-08-28 0:31 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-18 14:58 [Qemu-devel] is there a limit on the number of in-flight I/O operations? Chris Friesen
2014-07-18 15:24 ` Paolo Bonzini
2014-07-18 16:22 ` Chris Friesen
2014-07-18 20:13 ` Paolo Bonzini
2014-07-18 22:48 ` Chris Friesen
2014-07-19 5:49 ` Paolo Bonzini
2014-07-19 6:27 ` Chris Friesen
2014-07-19 7:23 ` Paolo Bonzini
2014-07-19 8:45 ` Benoît Canet
2014-07-21 14:59 ` Chris Friesen
2014-07-21 15:15 ` Benoît Canet
2014-07-21 15:35 ` Chris Friesen
2014-07-21 15:54 ` Benoît Canet
2014-07-21 16:10 ` Benoît Canet
2014-08-23 0:59 ` Chris Friesen
2014-08-23 7:56 ` Benoît Canet
2014-08-25 15:12 ` Chris Friesen
2014-08-25 17:43 ` Chris Friesen
2015-08-27 16:37 ` Stefan Hajnoczi
2015-08-27 16:33 ` Stefan Hajnoczi
2014-08-25 21:50 ` Chris Friesen
2014-08-27 5:43 ` Chris Friesen
2015-05-14 13:42 ` Andrey Korolyov
2015-08-26 17:10 ` Andrey Korolyov
2015-08-26 23:31 ` Josh Durgin
2015-08-26 23:47 ` Andrey Korolyov
2015-08-27 0:56 ` Josh Durgin
2015-08-27 16:48 ` Stefan Hajnoczi
2015-08-27 17:05 ` Stefan Hajnoczi
2015-08-27 16:49 ` Stefan Hajnoczi
2015-08-28 0:31 ` Josh Durgin [this message]
2015-08-28 8:31 ` Andrey Korolyov
2014-07-21 19:47 ` Benoît Canet
2014-07-21 21:12 ` Chris Friesen
2014-07-21 22:04 ` Benoît Canet
2014-07-18 15:54 ` Andrey Korolyov
2014-07-18 16:26 ` Chris Friesen
2014-07-18 16:30 ` Andrey Korolyov
2014-07-18 16:46 ` Chris Friesen
[not found] <1000957815.25879188.1441820902018.JavaMail.zimbra@redhat.com>
2015-09-09 18:51 ` Jason Dillaman
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=55DFABC8.5040006@redhat.com \
--to=jdurgin@redhat.com \
--cc=andrey@xdel.ru \
--cc=benoit.canet@irqsave.net \
--cc=chris.friesen@windriver.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.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).