Re: [PATCH 1/1] virtio-blk-ccw: tweak the default for num_queues

[Cornelia Huck]

On Wed, 11 Nov 2020 13:26:11 +0100
Michael Mueller <mimu@linux.ibm.com> wrote:

> On 10.11.20 15:16, Michael Mueller wrote:
> > 
> > 
> > On 09.11.20 19:53, Halil Pasic wrote:  
> >> On Mon, 9 Nov 2020 17:06:16 +0100
> >> Cornelia Huck <cohuck@redhat.com> wrote:
> >>  
> >>>> @@ -20,6 +21,11 @@ static void 
> >>>> virtio_ccw_blk_realize(VirtioCcwDevice *ccw_dev, Error **errp)
> >>>>   {
> >>>>       VirtIOBlkCcw *dev = VIRTIO_BLK_CCW(ccw_dev);
> >>>>       DeviceState *vdev = DEVICE(&dev->vdev);
> >>>> +    VirtIOBlkConf *conf = &dev->vdev.conf;
> >>>> +
> >>>> +    if (conf->num_queues == VIRTIO_BLK_AUTO_NUM_QUEUES) {
> >>>> +        conf->num_queues = MIN(4, current_machine->smp.cpus);
> >>>> +    }  
> >>>
> >>> I would like to have a comment explaining the numbers here, however.
> >>>
> >>> virtio-pci has a pretty good explanation (use 1:1 for vqs:vcpus if
> >>> possible, apply some other capping). 4 seems to be a bit arbitrary
> >>> without explanation, although I'm sure you did some measurements :)  
> >>
> >> Frankly, I don't have any measurements yet. For the secure case,
> >> I think Mimu has assessed the impact of multiqueue, hence adding Mimu to
> >> the cc list. @Mimu can you help us out.
> >>
> >> Regarding the normal non-protected VMs I'm in a middle of producing some
> >> measurement data. This was admittedly a bit rushed because of where we
> >> are in the cycle. Sorry to disappoint you.  
> > 
> > I'm talking with the perf team tomorrow. They have done some 
> > measurements with multiqueue for PV guests and I asked for a comparison 
> > to non PV guests as well.  
> 
> The perf team has performed measurements for us that show that a *PV
> KVM guest* benefits in terms of throughput for random read, random write
> and sequential read (no difference for sequential write) by a multi
> queue setup. CPU cost are reduced as well due to reduced spinlock
> contention.

Just to be clear, that was with 4 queues?

> 
> For a *standard KVM guest* it currently has no throughput effect. No
> benefit and no harm. I have asked them to finalize their measurements
> by comparing the CPU cost as well. I will receive that information on 
> Friday.

Thank you for checking!

> 
> Michael
> 
> 
> > 
> > Michael
> >   
> >>
> >> The number 4 was suggested by Christian, maybe Christian does have some
> >> readily available measurement data for the normal VM case. @Christian:
> >> can you help me out?
> >>
> >> Regards,
> >> Halil
> >>  
> >   
> 
>