Thread (133 messages) 133 messages, 13 authors, 2016-03-10

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help