On 29/08/2019 23:12, Joao Martins wrote: [ ... ] >>> Say you wanted to have a kvm specific config, you would still see the same >>> problem if you happen to compile intel_idle together with haltpoll >>> driver+governor. >> >> Can a guest work with an intel_idle driver? >> > Yes. > > If you use Qemu you would add '-overcommit cpu-pm=on' to try it out. ofc, > assuming you're on a relatively recent Qemu (v3.0+) and a fairly recent kernel > version as host (v4.17+). Ok, thanks for the clarification. >>> Creating two separate configs here, with and without haltpoll >>> for VMs doesn't sound effective for distros. >> >> Agree >> >>> Perhaps decreasing the rating of >>> haltpoll governor, but while a short term fix it wouldn't give much sensible >>> defaults without the one-off runtime switch. The rating has little meaning because each governor fits a specific situation (server, desktop, etc...) and it would probably make sense to remove it and add a default governor in the config file like the cpufreq. May be I missed the point from some previous discussion but IMHO the problem you are facing is coming from the design: there is no need to create a halt governor but move the code inside the cpuidle-halt driver instead and ignore the state asked by the governor and return the state the driver entered. -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
