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

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


On Tue, 14 Dec 2021 10:08:29 +0000,
Peter Maydell <peter.maydell@xxxxxxxxxx> wrote:
> On Tue, 14 Dec 2021 at 09:52, Marc Zyngier <maz@xxxxxxxxxx> 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.

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux