Re: [xen-4.12-testing test] 169199: regressions - FAIL

[Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>]

On 08/04/2022 16:26, Roger Pau Monne wrote:
> On Fri, Apr 08, 2022 at 12:24:27PM +0100, Julien Grall wrote:
>> Hi Roger,
>>
>> On 08/04/2022 12:16, Roger Pau Monné wrote:
>>> On Fri, Apr 08, 2022 at 12:08:02PM +0100, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 08/04/2022 12:01, Roger Pau Monné wrote:
>>>>>>> I could add a suitable dom0_max_vcpus parameter to osstest.  XenServer
>>>>>>> uses 16 for example.
>>>>>> I'm afraid a fixed number won't do, the more that iirc there are
>>>>>> systems with just a few cores in the pool (and you don't want to
>>>>>> over-commit by default).
>>>>> But this won't over commit, it would just assign dom0 16 vCPUs at
>>>>> most, if the system has less than 16 vCPUs that's what would be
>>>>> assigned to dom0.
>>>> AFAICT, this is not the case on Arm. If you ask 16 vCPUs, then you will get
>>>> that number even if there are 8 pCPUs.
>>>>
>>>> In fact, the documentation of dom0_max_vcpus suggests that the numbers of
>>>> vCPUs can be more than the number of pCPUs.
>>> It was my understanding that you could only achieve that by using the
>>> min-max nomenclature, so in order to force 16 vCPUs always you would
>>> have to use:
>>>
>>> dom0_max_vcpus=16-16
>>>
>>> Otherwise the usage of '_max_' in the option name is pointless, and it
>>> should instead be dom0_vcpus.
>>>
>>> Anyway, I could use:
>>>
>>> dom0_max_vcpus=1-16
>>>
>>> Which is unambiguous and should get us 1 vCPU at least, or 16vCPUs at
>>> most.
>> Unfortunately, Arm doesn't support the min-max nomenclature.
> Hm, can we update the command line document then?
>
> There's no mention that the min-max nomenclature is only available to
> x86. I assume it's not possible to share the logic here so that both
> Arm and x86 parse the option in the same way?

TBH, this especially wants moving to common code.  It's atrocious UX to
have per-arch variations on the syntax for "how many vcpus".

>>> But given Jans suggestion we might want to go for something more
>>> complex?
>> I think we already have some knowledge about each HW (i.e. grub vs uboot) in
>> Osstest. So I think it would be fine to extend the knowledge and add the
>> number of CPUs.
> We don't need to store this information anywhere I think. Since we
> first install plain Debian and then install Xen we can always fetch
> the number of physical CPUs when running plain Linux and use that to
> calculate the amount to give to dom0?
>
> Jan suggested using ceil(sqrt(nr_cpus)).

I'm going to play devils advocate here.

Our CI system had demonstrated that the default behaviour in Xen is
broken.  And we're saying "lets bodge around it in the CI system to not
use the default behaviour".


The only user-friendly way of resolving this is to fix the default and
leave the CI alone.

~Andrew