On Thu, 20 Mar 2025 at 19:30, <clement.aldeb...@univ-tlse3.fr> wrote: > To clarify, when we refer to energy consumption, we are specifically looking > at CPU core utilization. Our goal is to ensure that when we turn off CPU > cores on the emulated Raspberry Pi 3B, the host machine does not keep its > corresponding cores running at 100% utilization. > > This is particularly relevant for our use case, as our supervisor, M. Poquet, > intends to use this project for teaching operating system development. > Students using QEMU to emulate a Raspberry Pi 3B may have different host > machines, so our objective is to implement a general approach that ensures > CPU core deactivation works properly regardless of the host system. > > So far, our measurements indicate that even after turning off cores in the > emulated system, all CPU cores on the host remain at 100% utilization. We are > exploring ways to improve this behavior. > > We have looked into using -icount, but we would like to find a more viable > solution, particularly for the Cortex-A53 CPU used in the Raspberry Pi 3B. > Ideally, we would like to be able to use -smp 1 without being constrained by > QEMU’s limitations and to implement proper CPU core shutdown, similar to what > is available on x86-64 architectures. > > Would you have any recommendations or insights on achieving better power > management in this scenario?
You should check what mechanism you're trying to use to "turn off the cores"; there are several possibilities, some of which are "this ought to work, so if it isn't doing the right thing that's a bug to investigate", and some of which are "this is a feature that's not implemented at all right now": In the "should work" category: * if the CPU executes a WFI instruction we will stop executing code (until the next interrupt) * If you are using QEMU's PSCI implementation and you power the CPU down with e.g. PSCI CPU_OFF we should also stop executing code. (NB this is different from if you're running real guest firmware and the firmware is handling PSCI calls) In the "not implemented" category: * If you are trying to stop the CPU with a WFE instruction, we do not stop executing code (we emulate it as a NOP, which is architecturally permitted). * If you are trying to stop the CPU with some raspi-SoC-specific power controller, we don't currently have a model of that, I think If you need a working raspi SoC power controller device, the answer is that that power controller needs to be modelled so that when the guest uses it to turn off a CPU it makes the appropriate calls to arm_set_cpu_off() etc. This should be straightforward assuming that you have the appropriate datasheets/specs/etc describing the hardware behaviour. If you need WFE to work, that's certainly feasible and something it would be nice to see, but potentially quite a bit of work in the guts of QEMU's arm emulation. (Basically going to sleep on WFE is easy but then making sure that all the events and situations that need to wake up a WFE is tedious. We implement sleep-on-WFI but not sleep-on-WFI because the set of WFI-wakeup events is rather smaller than the WFE-wakeup events.) It's been in the "we really should implement this but since the only downside is the host CPUs spinning, we've never got round to it" bucket for years. (In the cases where we do stop executing code that means that that vCPU thread should no longer be doing a lot of work; obviously if your system has more vCPUs than host CPUs then the host CPUs will still all be busy.) Your other option here is "stop trying to use the raspberry pi machine types". The "virt" board, because it doesn't need to try to implement the same behaviour as an exact machine type, has a much easier job, and it already supports "you can have just one CPU with -smp 1" and "you can have an SMP system where you power off some of the CPUs while running". Basically "virt" is actively maintained, whereas the raspi machines are in the "Odd Fixes" state, which means we'll try to review patches but nobody is actively working on trying to make them better. thanks -- PMM
