On Fri, May 20, 2016 at 2:24 AM, Rafael J. Wysocki <[email protected]> wrote: > On Fri, May 20, 2016 at 1:34 AM, Steve Muckle <[email protected]> wrote: >> On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: >>> But anyway this change again seems to be an optimization that might be >>> done later to me. >>> >>> I guess there are many things that might be optimized in schedutil, >>> but I'd prefer to address one item at a time, maybe going after the >>> ones that appear most relevant first? >> >> Calling the last two patches in this series optimizations is a stretch >> IMO. Issuing frequency change requests that result in the same >> target-supported frequency is clearly unnecessary and ends up delaying >> more urgent frequency changes, which I think is more like a bug. > > The [4/5] is pulling stuff where it doesn't belong. Simple as that. > Frequency tables don't belong in schedutil, so don't pull them in > there. > > If you want to do that cleanly, add a call to the driver that will > tell you what frequency would be selected by it if it were given a > particular target.
Also I think that it would be good to avoid walking the frequency table twice in case we end up wanting to update the frequency after all. With the [4/5] we'd do it once in get_next_freq() and then once more in cpufreq_driver_fast_switch(), for example, and walking the frequency table may be more expensive that doing the switch in the first place.
