How did you switch to credit? Just by passing sched=credit on the Xen cmdline?
Also, to anyone interested, I’ve created a script to dynamically switch CPU pins based on the currently focused window :).
Forum thread: Dynamic, window focus-based CPU pinning
2 Likes
I think I’ve just uncovered a rather nasty bug. If the vcpu count in dom0 is set to anything other than the exact number of physical cores, the xen_acpi_processor kernel driver will fail to upload the C-state information for those cores to Xen, resulting in Xen never knowing about the C-states, which significantly impacts battery life.
You can check if you’re impacted by this by running xenpm start 1. If there are any CPUs that only display C0 and C1, then Xen doesn’t know about the additional C-states. The fix is to set the Xen boot parameter dom0_max_vcpus to your exact number of physical cores, including hyperthreading cores even if they’re disabled in software.
4 Likes
Also: this prevents s0ix sleep from working correctly.
Have you reported this upstream to Xen?
Also, do you know whether this impacts performance at all/in dom0 only/of all AppVMs?
Yes, I have reported the issue to the xen-devel mailing list.
The issue does not affect performance, but it impacts efficiency as it prevents Xen from throttling down the CPU. It shortens battery life in general and in s0ix sleep by an order of magnitude.
1 Like
It looks like not every cpu is affected.
I have alder lake i9-12900K and there even though I do like the first post instruction says - only have max dom0 vcpus at 4, xenpm sleep 1 still shows me C0 … C4 on all cores
Now with my mobile i7-13700H, when I do max dom0 vcpus at 4, then only first 4 show C0 … C3, and the rest of them only C0 and C1 just as you say (I am not sure what to think about lack of C4, was that removed in newer revisions?)
So I guess allowing max vcpus = 20 and then running
xl vcpu-set Domain-0 4
xl vcpu-pin Domain-0 all 16-19
would result in pretty much the desired behavior (and I confirmed that all CPUs show C0…C3 states)