Messages in this thread | | | From | Steve Muckle <> | Date | Tue, 31 May 2016 11:48:55 -0700 | Subject | Re: [PATCH v2 1/3] cpufreq: add resolve_freq driver callback |
| |
On Tue, May 31, 2016 at 11:00:11AM +0530, Viresh Kumar wrote: > On 30-05-16, 08:31, Steve Muckle wrote: > > My goal here was to have the system operate in this case in a manner > > that is obviously not optimized (running at fmax), so the platform owner > > realizes that the cpufreq driver doesn't fully support the schedutil > > governor. > > > > I was originally going to just return an error code but that also means > > having to check for it which would be nice to avoid if possible on this > > fast path. > > Okay, I get what you are saying. > > But all we are doing here is to make things fast by not sending IPIs, > etc. That should *not* lead to a behavior where the frequency stays at > MAX all the time even if the driver doesn't provide this callback or > the freq-table. > > If we just return the target_freq in this case instead of UINT_MAX, > the platform may eventually have some unnecessary IPIs, wakeups, etc, > but its frequency will still be switched properly. > > Wouldn't that be a better choice ?
I'm still concerned that a platform owner may use this and accept suboptimal perf/power because they aren't aware their cpufreq driver is not fully compliant. But I agree it'd be better to have it work as well as it can. I will make the change.
Maybe a warning message can be added when schedutil initializes if resolve_freq is not supported.
thanks, Steve
| |