just brew it! wrote:
Hit the first serious snag. Dicking around with the CPU power state governor and/or core count on the fly completely destabilizes VirtualBox. Went to use my Windows VM tonight and it kept crashing, and eventually got corrupted to the point it wouldn't boot any more; I had to restore the VM image from a recent backup.
No time to investigate further right now, I just disabled my power management script for the time being.
Perhaps you can change the script to check if a VirtualBox process is running and change the CPU to maximum performance + lower the polling rate while that process is running.
Yeah, I thought of doing that. I suspect the problem is with messing with the number of active cores (not the speed governor), but need to do some tests to verify that. If tests bear that out, then merely disabling the core enable/disable logic when VB is running ought to be sufficient.
Based on what I've seen these past few days, most (but not all) of the power savings seems to come from the governor tweaks anyway, since "disabling" a core doesn't really power it down, it just keeps the CPU scheduler from trying to use it.
I've already spent waaaaay more time than I intended on this...
Edit: I could easily imagine VB doing some sort of explicit affinity mapping of virtual to physical cores, then sh*tting the bed when the physical core one of the virtual cores is mapped to "goes away".
Edit 2: Perhaps anything that uses explicit core affinity is potentially vulnerable to this kind of (theorized) race condition. Ugh... down the rabbit hole we go.