From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XL6Cu-0000vx-Sy for qemu-devel@nongnu.org; Sat, 23 Aug 2014 03:57:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XL6Co-00038J-ON for qemu-devel@nongnu.org; Sat, 23 Aug 2014 03:57:52 -0400 Received: from lputeaux-656-01-25-125.w80-12.abo.wanadoo.fr ([80.12.84.125]:35185 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XL6Co-00038B-HZ for qemu-devel@nongnu.org; Sat, 23 Aug 2014 03:57:46 -0400 Date: Sat, 23 Aug 2014 09:56:58 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140823075658.GA6687@irqsave.net> References: <53C9A440.7020306@windriver.com> <53CA06ED.1090102@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <53F7E77A.9050509@windriver.com> Content-Transfer-Encoding: quoted-printable 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 The Friday 22 Aug 2014 =E0 18:59:38 (-0600), Chris Friesen wrote : > On 07/21/2014 10:10 AM, Beno=EEt Canet wrote: > >The Monday 21 Jul 2014 =E0 09:35:29 (-0600), Chris Friesen wrote : > >>On 07/21/2014 09:15 AM, Beno=EEt Canet wrote: > >>>The Monday 21 Jul 2014 =E0 08:59:45 (-0600), Chris Friesen wrote : > >>>>On 07/19/2014 02:45 AM, Beno=EEt Canet wrote: > >>>> > >>>>>I think in the throttling case the number of in flight operation i= s limited by > >>>>>the emulated hardware queue. Else request would pile up and thrott= ling would be > >>>>>inefective. > >>>>> > >>>>>So this number should be around: #define VIRTIO_PCI_QUEUE_MAX 64 o= r something like than that. > >>>> > >>>>Okay, that makes sense. Do you know how much data can be written a= s part of > >>>>a single operation? We're using 2MB hugepages for the guest memory= , and we > >>>>saw the qemu RSS numbers jump from 25-30MB during normal operation = up to > >>>>120-180MB when running dbench. I'd like to know what the worst-cas= e would > > > >Sorry I didn't understood this part at first read. > > > >In the linux guest can you monitor: > >benoit@Laure:~$ cat /sys/class/block/xyz/inflight ? > > > >This would give us a faily precise number of the requests actually in = flight between the guest and qemu. >=20 >=20 > After a bit of a break I'm looking at this again. >=20 Strange. I would use dd with the flag oflag=3Dnocache to make sure the write reque= st does not do in the guest cache though. Best regards Beno=EEt > While doing "dd if=3D/dev/zero of=3Dtestfile bs=3D1M count=3D700" in th= e guest, I > got a max "inflight" value of 181. This seems quite a bit higher than > VIRTIO_PCI_QUEUE_MAX. >=20 > I've seen throughput as high as ~210 MB/sec, which also kicked the RSS > numbers up above 200MB. >=20 > I tried dropping VIRTIO_PCI_QUEUE_MAX down to 32 (it didn't seem to wor= k at > all for values much less than that, though I didn't bother getting an e= xact > value) and it didn't really make any difference, I saw inflight values = as > high as 177. >=20 > Chris >=20