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

[Michael Mueller <mimu@linux.ibm.com>]

On 11.11.20 13:38, Cornelia Huck wrote:
> 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?

Yes, we have seen it with 4 and also with 9 queues.

Halil,

still I would like to know what the exact memory consumption per queue
is that you are talking about. Have you made a calculation? Thanks.

> 
>>
>> 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
>>>>   
>>>    
>>
>>
>