| Message ID | CAKohpoky1-hj7cwnKc58svh8Z1Yas1=q4uJEK8mWcb56uqAcng@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 08/06/2014 04:10 AM, Viresh Kumar wrote: > On 6 August 2014 03:36, Saravana Kannan <skannan@codeaurora.org> wrote: >> Stephen and I looked into this. This is not a sysfs framework difference. >> The reason we don't have this issue when we use global tunables is because >> we add the attribute group to the cpufreq_global_kobject and that kobject >> doesn't have a kobj_type ops similar to the per policy kobject. So, >> read/write to those attributes do NOT go through the generic show/store ops >> that wrap every other cpufreq framework attribute read/writes. >> >> So, none of those read/write do any kind of locking. They don't race with >> POLICY_EXIT (because we remove the sysfs group first thing in POLICY_EXIT) >> but might still race with START/STOPs (not sure, haven't looked closely >> yet). >> >> For example, writing to sampling_rate of ondemand governor might cause a >> race in update_sampling_rate(). It could race and happen between a STOP and >> POLICY_EXIT (triggered by hotplug, gov change, etc). > > This sounds good but I couldn't prove it. Doing this on my dual core exynos > doesn't give me that crash report and it should? Are you sure you're not seeing another lockdep warning? That was my problem -- there was an xfs related lockdep warning which then resulted in lockdep being disabled from that point on. P. > > diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c > index 1e0ec57..027b6f7 100644 > --- a/drivers/cpufreq/exynos-cpufreq.c > +++ b/drivers/cpufreq/exynos-cpufreq.c > @@ -139,7 +139,7 @@ static int exynos_cpufreq_cpu_init(struct > cpufreq_policy *policy) > } > > static struct cpufreq_driver exynos_driver = { > - .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK, > + .flags = CPUFREQ_STICKY | > CPUFREQ_NEED_INITIAL_FREQ_CHECK | CPUFREQ_HAVE_GOVERNOR_PER_POLICY, > .verify = cpufreq_generic_frequency_table_verify, > .target_index = exynos_target, > .get = cpufreq_generic_get, > -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/06, Prarit Bhargava wrote: > > > On 08/06/2014 04:10 AM, Viresh Kumar wrote: > > On 6 August 2014 03:36, Saravana Kannan <skannan@codeaurora.org> wrote: > >> Stephen and I looked into this. This is not a sysfs framework difference. > >> The reason we don't have this issue when we use global tunables is because > >> we add the attribute group to the cpufreq_global_kobject and that kobject > >> doesn't have a kobj_type ops similar to the per policy kobject. So, > >> read/write to those attributes do NOT go through the generic show/store ops > >> that wrap every other cpufreq framework attribute read/writes. > >> > >> So, none of those read/write do any kind of locking. They don't race with > >> POLICY_EXIT (because we remove the sysfs group first thing in POLICY_EXIT) > >> but might still race with START/STOPs (not sure, haven't looked closely > >> yet). > >> > >> For example, writing to sampling_rate of ondemand governor might cause a > >> race in update_sampling_rate(). It could race and happen between a STOP and > >> POLICY_EXIT (triggered by hotplug, gov change, etc). > > > > This sounds good but I couldn't prove it. Doing this on my dual core exynos > > doesn't give me that crash report and it should? > > Are you sure you're not seeing another lockdep warning? That was my problem -- > there was an xfs related lockdep warning which then resulted in lockdep being > disabled from that point on. > Are we talking about the lockdep splat or the crash that started this thread or something else? For the lockdep splat you need the corrected patch in this thread and the per policy governor flag. I'm not sure how to recreate the crash that started this thread.
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c index 1e0ec57..027b6f7 100644 --- a/drivers/cpufreq/exynos-cpufreq.c +++ b/drivers/cpufreq/exynos-cpufreq.c @@ -139,7 +139,7 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy) } static struct cpufreq_driver exynos_driver = { - .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK, + .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK | CPUFREQ_HAVE_GOVERNOR_PER_POLICY, .verify = cpufreq_generic_frequency_table_verify,