On Tue, 10 Nov 2020 09:47:51 +0100
Christian Borntraeger <borntrae...@de.ibm.com> wrote:
> On 09.11.20 19:53, Halil Pasic wrote:
> > On Mon, 9 Nov 2020 17:06:16 +0100
> > Cornelia Huck <coh...@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.
> >
> > 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?
> My point was to find a balance between performance gain and memory usage.
> As a matter of fact, virtqueue do consume memory. So 4 looked like a
> reasonable default for me for large guests as long as we do not have directed
> interrupts.
Yes, 4 does not look like a bad number, but I still don't feel really
comfortable with it without at least some data.
What about large guests with slow vs. fast storage?
>
> Now, thinking about this again: If we want to change the default to something
> else in the future (e.g. to num vcpus) then the compat handling will get
> really complicated.
Yes, I fear that will be messy. Just picking a value later will need
compat handling, but not a really complicated one.
>
> So we can
> - go with num queues = num cpus. But this will consume memory
> for guests with lots of CPUs.
I'm not sure that would be a good choice, as we don't have the benefits
that pci has.
> - go with the proposed logic of min(4,vcpus) and accept that future compat
> handling
> is harder
With a bit more data, I'd be way more comfortable. Might still be ok
for the next rc.
> - defer this change
We might end up with that, given the timing :( (not blaming anyone)
