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. M. [1] /sys/devices/system/cpu/cpu*/cpu_capacity -- Without deviation from the norm, progress is not possible.
