On Wed, Feb 12, 2020 at 11:18:32AM +0000, Stefan Hajnoczi wrote: > On Tue, Feb 11, 2020 at 11:31:17AM -0500, Michael S. Tsirkin wrote: > > On Tue, Feb 11, 2020 at 04:20:41PM +0000, Stefan Hajnoczi wrote: > > > On Mon, Feb 03, 2020 at 12:39:49PM +0100, Sergio Lopez wrote: > > > > On Mon, Feb 03, 2020 at 10:57:44AM +0000, Daniel P. Berrangé wrote: > > > > > On Mon, Feb 03, 2020 at 11:25:29AM +0100, Sergio Lopez wrote: > > > > > > On Thu, Jan 30, 2020 at 10:52:35AM +0000, Stefan Hajnoczi wrote: > > > > > > > On Thu, Jan 30, 2020 at 01:29:16AM +0100, Paolo Bonzini wrote: > > > > > > > > On 29/01/20 16:44, Stefan Hajnoczi wrote: > > > > > > > > > On Mon, Jan 27, 2020 at 02:10:31PM +0100, Cornelia Huck wrote: > > > > > > > > >> On Fri, 24 Jan 2020 10:01:57 +0000 > > > > > > > > >> Stefan Hajnoczi <stefa...@redhat.com> wrote: > > > I will create a 32 vCPU guest with 100 virtio-blk devices and verify > > > that enabling multi-queue is successful. > > > > and that it's helpful for performance? > > I may be a little while before the next revision of this patch series. > Testing reveals scalability problems when creating so many virtqueues > :). > > I've measured boot time, memory consumption, and random read IOPS. They > are all significantly worse (32 vCPUs, 24 GB RAM, 101 virtio-blk > devices, 32 queues/device). > > Time to see what's going on and whether some general scalability > improvements are possible here before we enable multi-queue by default.
Update: Boot time has improved with "[PATCH] memory: batch allocate ioeventfds[] in address_space_update_ioeventfds()". IOPS looks a lot better with the O(1) QEMU event loop patches that I've posted. This work is not complete yet, I still need to make AioContext polling O(1) too (it consumes too much CPU with many idle devices). After this work is complete I'll measure boot time, memory consumption, and IOPS again. Then we can decide whether multiqueue by default is a good idea. Stefan
signature.asc
Description: PGP signature