[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Libvirt on little.BIG ARM systems unable to start guest if no cpuset

From: Marc Zyngier
Subject: Re: Libvirt on little.BIG ARM systems unable to start guest if no cpuset is provided
Date: Tue, 14 Dec 2021 10:33:53 +0000
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (Gojō) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

On Tue, 14 Dec 2021 10:08:29 +0000,
Peter Maydell <peter.maydell@linaro.org> wrote:
> On Tue, 14 Dec 2021 at 09:52, Marc Zyngier <maz@kernel.org> wrote:
> > The best workaround is to taskset the QEMU process (and I really mean
> > the process, not individual threads) to an homogeneous set of CPUs and
> > be done with it.
> Agreed. I suspect that often the 'little' CPUs are sufficiently
> low-power to probably not be worth giving to the VM anyway.

They are actually pretty beefy, in most cases. If you are I/O bound,
the small cores are the right target. This email is brought to you via
a couple of A55 CPUs running a VM and acting as my home gateway. If
'the internet' was getting slow, I'd have heard about it! ;-)

> Side note: if you *do* give a guest both big and little CPUs
> using kvmtool or something similar, does the guest kernel get
> enough information to schedule tasks properly to both kinds of
> CPU, or does it just assume they're all the same and happily
> put performance-requiring tasks on the little CPUs ?

Upstream kvmtool doesn't make any effort to do this, but I had a
series to perform such placement in the past. Once you know which
physical CPUs you are placing the vcpus on, you can extract the
individual CPU capacity[1] and expose it in the guest's DT as a
cpu-specific 'capacity-dmips-mhz' property. A Linux guest will take
the hint and do the right thing.


[1] /sys/devices/system/cpu/cpu*/cpu_capacity

Without deviation from the norm, progress is not possible.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]