On 02/19/2016 08:42 AM, Srinivas Pandruvada wrote: > We did experiments using util/max in intel_pstate. For some benchmarks > there were regression of 4 to 5%, for some benchmarks it performed at > par with getting utilization from the processor. Further optimization > in the algorithm is possible and still in progress. Idea is that we can > change P-State fast enough and be more reactive. Once I have good data, > I will send to this list. The algorithm can be part of the cpufreq > governor too.
There has been a lot of work in the area of scheduler-driven CPU frequency selection by Linaro and ARM as well. It was posted most recently a couple months ago: http://thread.gmane.org/gmane.linux.power-management.general/69176 It was also posted as part of the energy-aware scheduling series last July. There's a new RFC series forthcoming which I had hoped (and failed) to post prior to my business travel this week; it should be out next week. It will address the feedback received thus far along with locking and other things. The scheduler hooks for utilization-based cpufreq operation deserve a lot more debate I think. They could quite possibly have different requirements than hooks which are chosen just to guarantee periodic callbacks into sampling-based governors. For my part I think it would be best if the util/max parameters are omitted until it's clear whether these same hooks can be effectively used for architecture agnostic scheduler-guided (capacity driven) CPU frequency support. My upcoming RFC will provide another opportunity to debate the hooks as well as how scheduler-guided CPU frequency should be structured. thanks, Steve
