Thread (31 messages) 31 messages, 5 authors, 2021-08-23

Re: [PATCH v4 0/9] Inefficient OPPs

From: Vincent Donnefort <hidden>
Date: 2021-08-23 17:06:33

On Tue, Aug 17, 2021 at 10:03:53AM +0100, Lukasz Luba wrote:

On 8/17/21 8:06 AM, Viresh Kumar wrote:
quoted
On 16-08-21, 16:19, Rafael J. Wysocki wrote:
quoted
On Tue, Aug 10, 2021 at 8:13 AM Viresh Kumar [off-list ref] wrote:
quoted
 I understand  that this was done to not do the efficient stuff in case of
  userspace/powersave/performance governors.

  What about reusing following for finding all such cases ?

        policy->governor->flags & CPUFREQ_GOV_DYNAMIC_SWITCHING

  The driver can set a flag to tell if it wants efficient frequencies
  or not, and at runtime we apply efficient algorithm only if the
  current governor does DVFS, which will leave out
  userspace/performance/powersave.
As long as this can be done without actually accessing
policy->governor->flags on every transition, it sounds like a good
idea.
Great.

Vincent, I hope you will be taking this forward then ?
Vincent has been on vacations for quite a while, but he will be back
next week.

Thank you guys for the comments.
Sorry, I was indeed off for few weeks, that's why I was silent until now.
Looks like I missed the party here. But if I sum-up what you discussed in
the thread:

  * With a newly introduced callback .register_em(), we could use the EM
    table to mark inefficiencies into the CPUFreq table from the CPUFreq
    driver.

  * Instead of having a RELATION_E, resolving inefficiencies to efficient
    frequencies whenever the driver supports it and the governor declares
    CPUFREQ_GOV_DYNAMIC_SWITCHING.

I'll have a look and I'll prepare a new version, based on:

  [PATCH V3 0/9] Add callback to register with energy model 

-- 
Vincent
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help