Re: [PATCH V5 0/2] sched: cpufreq: Allow remote callbacks
From: Rafael J. Wysocki
Date: Tue Aug 01 2017 - 19:30:59 EST
On Friday, July 28, 2017 12:16:37 PM Viresh Kumar wrote:
> With Android UI and benchmarks the latency of cpufreq response to
> certain scheduling events can become very critical. Currently, callbacks
> into cpufreq governors are only made from the scheduler if the target
> CPU of the event is the same as the current CPU. This means there are
> certain situations where a target CPU may not run the cpufreq governor
> for some time.
> One testcase  to show this behavior is where a task starts running on
> CPU0, then a new task is also spawned on CPU0 by a task on CPU1. If the
> system is configured such that the new tasks should receive maximum
> demand initially, this should result in CPU0 increasing frequency
> immediately. But because of the above mentioned limitation though, this
> does not occur.
> This series updates the scheduler core to call the cpufreq callbacks for
> remote CPUs as well and updates the registered hooks to handle that.
> This is tested with couple of usecases (Android: hackbench, recentfling,
> galleryfling, vellamo, Ubuntu: hackbench) on ARM hikey board (64 bit
> octa-core, single policy). Only galleryfling showed minor improvements,
> while others didn't had much deviation.
> The reason being that this patch only targets a corner case, where
> following are required to be true to improve performance and that
> doesn't happen too often with these tests:
> - Task is migrated to another CPU.
> - The task has high demand, and should take the target CPU to higher
> - And the target CPU doesn't call into the cpufreq governor until the
> next tick.
> Rebased over: pm/linux-next
> - Drop cpu field from "struct update_util_data" and add it in "struct
> sugov_cpu" instead.
> - Can't have separate patches now because of the above change and so
> merged all the patches from V4 into a single patch.
> - Add a comment suggested by PeterZ.
> - Commit log of 1/2 is improved to contain more details.
> - A new patch (which was posted during V1) is also added to take care of
> platforms where any CPU can do DVFS on behalf of any other CPU, even
> if they are part of different cpufreq policies. This has been
> requested by Saravana several times already and as the series is quite
> straight forward now, I decided to include it in.
> - Respect iowait boost flag and util updates for the all remote
> - Minor updates in commit log of 2/3.
> - Rearranged/merged patches as suggested by Rafael (looks much better
> - Also handle new hook added to intel-pstate driver.
> - The final code remains the same as V2, except for the above hook.
> - Don't support remote callbacks for unshared cpufreq policies.
> - Don't support remote callbacks where local CPU isn't part of the
> target CPU's cpufreq policy.
> - Dropped dvfs_possible_from_any_cpu flag.
Applied with the tags from Peter and Saravana.