The Monday 21 Jul 2014 à 09:35:29 (-0600), Chris Friesen wrote : > On 07/21/2014 09:15 AM, Benoît Canet wrote: > >The Monday 21 Jul 2014 à 08:59:45 (-0600), Chris Friesen wrote : > >>On 07/19/2014 02:45 AM, Benoît Canet wrote: > >> > >>>I think in the throttling case the number of in flight operation is > >>>limited by > >>>the emulated hardware queue. Else request would pile up and throttling > >>>would be > >>>inefective. > >>> > >>>So this number should be around: #define VIRTIO_PCI_QUEUE_MAX 64 or > >>>something like than that. > >> > >>Okay, that makes sense. Do you know how much data can be written as 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-case 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. Best regards Benoît > >>be. > > > >I think Linux as a limit of 512Kb for io size or something like that. > >So the guest would have VIRTIO_PCI_QUEUE_MAX * 512Kb of in flight buffers at > >max. > > Those numbers don't line up with what we were seeing...we saw a 120MB+ jump > when running dbench, which would map to more like 2MB per operation assuming > a limit of VIRTIO_PCI_QUEUE_MAX (i.e. 64). > > Unless there are other buffers involved that we haven't factored in... > > Chris > >
