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? Regards, Wanpeng Li