Hi Dear Poynor/All cpufreq owner,

I found a kernel panic case caused by interactive governor when we
enabled both hotplug governor and linked cpufreq features.

Below is the background and root cause,
We are using the latest interactive governor on dual ca9 smp system,
and linked cpufreq feature(cpumask_setall(policy->cpus) for each cpus)
is enabled for them.  Based on it, cpufreq governor could consider the
both cpu's workload and make decision for the smp cores.  And we also
have a hotplug governor to monitor the system workload to make
decision when will cpu1 could be hotplugged.
1. The default cpufreq governor during boot up is userspace.

2.  After system is boot up, hotplug governor found system has no
workload and cpu1 was hotplugged. Hotplug notifier will set cpu0’s
policy->cpus only for cpu0.

3.  After that,  Cpufreq governor switched  to Interactive, and its
CPUFREQ_GOV_START will only init the cpu0’s info struct, such as
pcpu->policy and governor_enabled etc.

4.  A boost event comes, such as touching the screen, it will lead to
CPU1 is plugged in at first, that means cpu0’s policy->cpus is linked
to cpu0&cpu1 again, but it will not call interactive governor’s
CPUFREQ_GOV_START to initialize cpu1’s info struct.

5. After that cpu0’s frequency changed, and it will notify interactive
governor, in the notifier function(cpufreq_interactive_notifier) it
will call update_load and access CPU1’s pcpu->policy->cur,  but it is
never initialized and lead to kernel panic.



In current interactive governor, if the governor is started after cpu1
is plugged out, later even the cpu1 is plugged in, it still won’t
consider cpu1’s status as it thinks cpu1’s governor_enabled is still
0, cpu1's profiling timer will just return in case it thinks
interactive governor is not enabled on cpu1. So the linked feature
could not ensure it makes decision based on the max load of cpu0 and
cpu1 on smp.  It is not what we expected.

But there is no such issue in b.L system as all cpu has no link
relationship. Looks like interactive governor doesn’t consider much
for SMP.


I made a draft patch to solve the panic as below, but still could
solve the issue interactive is enabled after cpu1 is hotplugged.
Could you please take a look how to solve the interactive governor
issue for SMP?

Thanks.



Date: Thu, 28 Mar 2013 14:03:40 +0800

Subject: [PATCH] cpufreq: interactive: fix race condition of hotplug
and linked cpufreq



Signed-off-by: Zhoujie Wu <zhouji...@gmail.com>

---

 drivers/cpufreq/cpufreq_interactive.c |    2 ++

 1 files changed, 2 insertions(+), 0 deletions(-)



diff --git a/drivers/cpufreq/cpufreq_interactive.c
b/drivers/cpufreq/cpufreq_interactive.c

index 7d1952c..6941201 100644

--- a/drivers/cpufreq/cpufreq_interactive.c

+++ b/drivers/cpufreq/cpufreq_interactive.c

@@ -565,6 +565,8 @@ static int cpufreq_interactive_notifier(

                for_each_cpu(cpu, pcpu->policy->cpus) {

                        struct cpufreq_interactive_cpuinfo *pjcpu =

                                &per_cpu(cpuinfo, cpu);

+                       if (!pjcpu->governor_enabled)

+                         continue;

                        spin_lock_irqsave(&pjcpu->load_lock, flags);

                        update_load(cpu);

                        spin_unlock_irqrestore(&pjcpu->load_lock, flags);

--

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to