sched/cpufreq: Align trace event behavior of fast switching
diff mbox series

Message ID 20190807153340.11516-1-douglas.raillard@arm.com
State New
Headers show
Series
  • sched/cpufreq: Align trace event behavior of fast switching
Related show

Commit Message

Douglas Raillard Aug. 7, 2019, 3:33 p.m. UTC
Fast switching path only emits an event for the CPU of interest, whereas the
regular path emits an event for all the CPUs that had their frequency changed,
i.e. all the CPUs sharing the same policy.

With the current behavior, looking at cpu_frequency event for a given CPU that
is using the fast switching path will not give the correct frequency signal.

Signed-off-by: Douglas RAILLARD <douglas.raillard@arm.com>
---
 kernel/sched/cpufreq_schedutil.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Comments

Rafael J. Wysocki Aug. 7, 2019, 8:40 p.m. UTC | #1
On Wed, Aug 7, 2019 at 5:34 PM Douglas RAILLARD
<douglas.raillard@arm.com> wrote:
>
> Fast switching path only emits an event for the CPU of interest, whereas the
> regular path emits an event for all the CPUs that had their frequency changed,
> i.e. all the CPUs sharing the same policy.
>
> With the current behavior, looking at cpu_frequency event for a given CPU that
> is using the fast switching path will not give the correct frequency signal.

Do you actually have any systems where that is a problem?  If so, then
what are they?
Douglas Raillard Aug. 8, 2019, 4:18 p.m. UTC | #2
Hi Rafael,

On 8/7/19 9:40 PM, Rafael J. Wysocki wrote:
> On Wed, Aug 7, 2019 at 5:34 PM Douglas RAILLARD
> <douglas.raillard@arm.com> wrote:
>>
>> Fast switching path only emits an event for the CPU of interest, whereas the
>> regular path emits an event for all the CPUs that had their frequency changed,
>> i.e. all the CPUs sharing the same policy.
>>
>> With the current behavior, looking at cpu_frequency event for a given CPU that
>> is using the fast switching path will not give the correct frequency signal.
> 
> Do you actually have any systems where that is a problem?  If so, then
> what are they?
> 

That happens on Google Pixel 3 smartphone, which uses this cpufreq driver: drivers/cpufreq/qcom-cpufreq-hw.c.

[1] git clone https://git.linaro.org/people/amit.pundir/linux.git -b blueline-mainline-tracking

Thanks,
Douglas

Patch
diff mbox series

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 1f82ab108bab..975ccc3de807 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -153,6 +153,7 @@  static void sugov_fast_switch(struct sugov_policy *sg_policy, u64 time,
 			      unsigned int next_freq)
 {
 	struct cpufreq_policy *policy = sg_policy->policy;
+	int cpu;
 
 	if (!sugov_update_next_freq(sg_policy, time, next_freq))
 		return;
@@ -162,7 +163,11 @@  static void sugov_fast_switch(struct sugov_policy *sg_policy, u64 time,
 		return;
 
 	policy->cur = next_freq;
-	trace_cpu_frequency(next_freq, smp_processor_id());
+
+	if (trace_cpu_frequency_enabled()) {
+		for_each_cpu(cpu, policy->cpus)
+			trace_cpu_frequency(next_freq, cpu);
+	}
 }
 
 static void sugov_deferred_update(struct sugov_policy *sg_policy, u64 time,