On Fri, May 27, 2016 at 01:41:02PM +0800, Wanpeng Li wrote: > 2016-05-26 10:53 GMT+08:00 Steve Muckle <steve.muc...@linaro.org>: > > The slow-path frequency transition path is relatively expensive as it > > requires waking up a thread to do work. Should support be added for > > remote CPU cpufreq updates that is also expensive since it requires an > > IPI. These activities should be avoided if they are not necessary. > > > > To that end, calculate the actual driver-supported frequency required by > > the new utilization value in schedutil by using the recently added > > cpufreq_driver_resolve_freq callback. If it is the same as the > > previously requested driver frequency then there is no need to continue > > with the update assuming the cpu frequency limits have not changed. This > > will have additional benefits should the semantics of the rate limit be > > changed to apply solely to frequency transitions rather than to > > frequency calculations in schedutil. > > sugov_should_update_freq() still be called before get_nex_freq() after > the patch applied, so rate limit still apply to both frequency > transitions and frequency calculations, right?
Yes this series does not change the semantics of the rate limit. It only includes the changes required for resolving raw target frequencies to driver-supported frequencies so redundant operations can be avoided. FWIW the approach I took to change the rate_limit semantics [0] just moves where last_freq_update_time is set. I was going to return to that once these changes are complete. [0]: https://lkml.org/lkml/2016/5/9/857 thanks, Steve
