Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks
From: Juri Lelli <hidden>
Date: 2016-02-19 17:25:18
Also in:
lkml
Hi Srinivas, On 19/02/16 08:42, Srinivas Pandruvada wrote:
On Fri, 2016-02-19 at 08:09 +0000, Juri Lelli wrote: Hi Juri,quoted
quoted
Hi Rafael, On 18/02/16 21:22, Rafael J. Wysocki wrote:quoted
On Mon, Feb 15, 2016 at 10:47 PM, Rafael J. Wysocki <rjw@rjwysocki. net> wrote:quoted
From: Rafael J. Wysocki <redacted>[...]quoted
However, I still don't quite get why we want to introduce an interface for explicit passing of util and max if we are not using such parameters yet. Also, I couldn't find any indication of how such parameters will be used in the future. If what we need today is a periodic kick for cpufreq governors that need it, we should simply do how we already do for RT and DL, IMHO. Also because the places where the current hooks reside might not be the correct and useful one once we'll start using the utilization parameters. I could probably make a case for DL where we should place hooks in admission control path (or somewhere else when more sophisticated mechanisms we'll be in place) rather then in the periodic tick.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.
Thanks for your answer. What you are experimenting with looks really interesting and I'm certainly more than interested in looking at your findings and patches when they will hit the list. My point was more on what we can look at today, though. Without a clear understanding about how and where util and max will be used and from which scheduler paths such information should come from, it is a bit difficult to tell if the current interface and hooks are fine, IMHO. I'd suggest we leave this part to the discussion we will have once your proposal will be public; and to facilitate that we should remove those arguments from the current interface. Best, - Juri