From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV0NF-0003dt-7S for qemu-devel@nongnu.org; Thu, 27 Aug 2015 12:50:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZV0NA-0001jk-8v for qemu-devel@nongnu.org; Thu, 27 Aug 2015 12:50:01 -0400 Received: from mail-wi0-x233.google.com ([2a00:1450:400c:c05::233]:35073) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV0NA-0001jZ-3E for qemu-devel@nongnu.org; Thu, 27 Aug 2015 12:49:56 -0400 Received: by wicne3 with SMTP id ne3so80693223wic.0 for ; Thu, 27 Aug 2015 09:49:55 -0700 (PDT) Date: Thu, 27 Aug 2015 17:49:52 +0100 From: Stefan Hajnoczi Message-ID: <20150827164952.GE8298@stefanha-thinkpad.redhat.com> References: <53CA0FC4.8080802@windriver.com> <53CA1D06.9090601@redhat.com> <20140719084537.GA3058@irqsave.net> <53CD2AE1.6080803@windriver.com> <20140721151540.GA22161@irqsave.net> <53CD3341.60705@windriver.com> <20140721161034.GC22161@irqsave.net> <53F7E77A.9050509@windriver.com> <20140823075658.GA6687@irqsave.net> <53FBAF8A.3050005@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53FBAF8A.3050005@windriver.com> Subject: Re: [Qemu-devel] is there a limit on the number of in-flight I/O operations? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chris Friesen Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , Paolo Bonzini , qemu-devel@nongnu.org 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. Instead rbd should be adjusted to support iovecs as you suggested. That way no bounce buffers are needed. Stefan