Hi,
On 11/22/19 11:19 AM, Andrew Jones wrote:
> On Fri, Nov 22, 2019 at 10:45:08AM +0000, Alexandru Elisei wrote:
>> Hi,
>>
>> On 11/20/19 2:19 PM, Andrew Jones wrote:
>>> We can only use online cpus, so make sure we check specifically for
>>> those.
>>>
>>> Signed-off-by: Andrew Jones <drjones@xxxxxxxxxx>
>>> ---
>>> scripts/runtime.bash | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/scripts/runtime.bash b/scripts/runtime.bash
>>> index 200d5b67290c..fbad0bd05fc5 100644
>>> --- a/scripts/runtime.bash
>>> +++ b/scripts/runtime.bash
>>> @@ -1,5 +1,5 @@
>>> : "${RUNTIME_arch_run?}"
>>> -: ${MAX_SMP:=$(getconf _NPROCESSORS_CONF)}
>>> +: ${MAX_SMP:=$(getconf _NPROCESSORS_ONLN)}
>> I tested it on my machine by offlining a CPU and calling getconf _NPROCESSORS_CONF
>> (returned 32) and getconf _NPROCESSORS_ONLN (returned 31). man 3 sysconf also
>> agrees with your patch.
>>
>> I am wondering though, if _NPROCESSORS_CONF is 8 and _NPROCESSORS_ONLN is 1
>> (meaning that 7 CPUs were offlined), that means that qemu will create 8 VCPUs
>> which will share the same physical CPU. Is that undesirable?
> With KVM enabled that's not recommended. KVM_CAP_NR_VCPUS returns the
> number of online VCPUs (at least for arm). Since the guest code may not
> run as expected with overcommitted VCPUs we don't usually want to test
Can you give more details about what may go wrong if several kvm-unit-tests VCPUs
run on the same physical CPU? I was thinking that maybe we want to run the VCPUs
in parallel (each on its own physical CPU) to detect races in KVM, not because of
a limitation in kvm-unit-tests.
Thanks,
Alex
> that way. OTOH, maybe we should write a test or two that does run with
> overcommitted VCPUs in order to look for bugs in KVM.
>
> Thanks,
> drew
>> Thanks,
>> Alex
>>> : ${TIMEOUT:=90s}
>>>
>>> PASS() { echo -ne "\e[32mPASS\e[0m"; }
