Messages in this thread | | | Subject | Re: Default governor regardless of cpuidle driver | From | Daniel Lezcano <> | Date | Thu, 29 Aug 2019 23:51:46 +0200 |
| |
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
| |