| Message ID | 20130711221553.547.56787.stgit@srivatsabhat.in.ibm.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On 12 July 2013 03:45, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: > The call to cpufreq_update_policy() is placed in the CPU hotplug callback > of cpufreq_stats, which has a higher priority than the CPU hotplug callback > of cpufreq-core. As a result, during CPU_ONLINE/CPU_ONLINE_FROZEN, we end up > calling cpufreq_update_policy() *before* calling cpufreq_add_dev() ! > And for uninitialized CPUs, it just returns silently, not doing anything. Hmm.. > To add to it, cpufreq_stats is not even the right place to call > cpufreq_update_policy() to begin with. The cpufreq core ought to handle > this in its own callback, from an elegance/relevance perspective. > > So move the invocation of cpufreq_update_policy() to cpufreq_cpu_callback, > and place it *after* cpufreq_add_dev(). > > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > --- > > drivers/cpufreq/cpufreq.c | 1 + > drivers/cpufreq/cpufreq_stats.c | 6 ------ > 2 files changed, 1 insertion(+), 6 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index ccc6eab..f8c3100 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -1943,6 +1943,7 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, > case CPU_ONLINE: > case CPU_ONLINE_FROZEN: > cpufreq_add_dev(dev, NULL); > + cpufreq_update_policy(cpu); Do we need to call this for every hotplug of cpu? I am not talking about suspend/resume here. -- 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 07/12/2013 12:36 PM, Viresh Kumar wrote: > On 12 July 2013 03:45, Srivatsa S. Bhat > <srivatsa.bhat@linux.vnet.ibm.com> wrote: >> The call to cpufreq_update_policy() is placed in the CPU hotplug callback >> of cpufreq_stats, which has a higher priority than the CPU hotplug callback >> of cpufreq-core. As a result, during CPU_ONLINE/CPU_ONLINE_FROZEN, we end up >> calling cpufreq_update_policy() *before* calling cpufreq_add_dev() ! >> And for uninitialized CPUs, it just returns silently, not doing anything. > > Hmm.. > >> To add to it, cpufreq_stats is not even the right place to call >> cpufreq_update_policy() to begin with. The cpufreq core ought to handle >> this in its own callback, from an elegance/relevance perspective. >> >> So move the invocation of cpufreq_update_policy() to cpufreq_cpu_callback, >> and place it *after* cpufreq_add_dev(). >> >> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> >> --- >> >> drivers/cpufreq/cpufreq.c | 1 + >> drivers/cpufreq/cpufreq_stats.c | 6 ------ >> 2 files changed, 1 insertion(+), 6 deletions(-) >> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c >> index ccc6eab..f8c3100 100644 >> --- a/drivers/cpufreq/cpufreq.c >> +++ b/drivers/cpufreq/cpufreq.c >> @@ -1943,6 +1943,7 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, >> case CPU_ONLINE: >> case CPU_ONLINE_FROZEN: >> cpufreq_add_dev(dev, NULL); >> + cpufreq_update_policy(cpu); > > Do we need to call this for every hotplug of cpu? I am not > talking about suspend/resume here. > I don't think we need to, but I think it would be better to postpone optimizations until all the cpufreq regressions get fixed. Later perhaps we could revisit these minor optimizations if desired. Regards, Srivatsa S. Bhat -- 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 Monday, July 15, 2013 11:50:24 AM Srivatsa S. Bhat wrote: > On 07/12/2013 12:36 PM, Viresh Kumar wrote: > > On 12 July 2013 03:45, Srivatsa S. Bhat > > <srivatsa.bhat@linux.vnet.ibm.com> wrote: > >> The call to cpufreq_update_policy() is placed in the CPU hotplug callback > >> of cpufreq_stats, which has a higher priority than the CPU hotplug callback > >> of cpufreq-core. As a result, during CPU_ONLINE/CPU_ONLINE_FROZEN, we end up > >> calling cpufreq_update_policy() *before* calling cpufreq_add_dev() ! > >> And for uninitialized CPUs, it just returns silently, not doing anything. > > > > Hmm.. > > > >> To add to it, cpufreq_stats is not even the right place to call > >> cpufreq_update_policy() to begin with. The cpufreq core ought to handle > >> this in its own callback, from an elegance/relevance perspective. > >> > >> So move the invocation of cpufreq_update_policy() to cpufreq_cpu_callback, > >> and place it *after* cpufreq_add_dev(). > >> > >> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > >> --- > >> > >> drivers/cpufreq/cpufreq.c | 1 + > >> drivers/cpufreq/cpufreq_stats.c | 6 ------ > >> 2 files changed, 1 insertion(+), 6 deletions(-) > >> > >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > >> index ccc6eab..f8c3100 100644 > >> --- a/drivers/cpufreq/cpufreq.c > >> +++ b/drivers/cpufreq/cpufreq.c > >> @@ -1943,6 +1943,7 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, > >> case CPU_ONLINE: > >> case CPU_ONLINE_FROZEN: > >> cpufreq_add_dev(dev, NULL); > >> + cpufreq_update_policy(cpu); > > > > Do we need to call this for every hotplug of cpu? I am not > > talking about suspend/resume here. > > > > I don't think we need to, but I think it would be better to postpone > optimizations until all the cpufreq regressions get fixed. Later perhaps > we could revisit these minor optimizations if desired. Agreed. Thanks, Rafael
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index ccc6eab..f8c3100 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1943,6 +1943,7 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, case CPU_ONLINE: case CPU_ONLINE_FROZEN: cpufreq_add_dev(dev, NULL); + cpufreq_update_policy(cpu); break; case CPU_DOWN_PREPARE: case CPU_DOWN_PREPARE_FROZEN: diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c index 12225d1..a3e7475 100644 --- a/drivers/cpufreq/cpufreq_stats.c +++ b/drivers/cpufreq/cpufreq_stats.c @@ -348,10 +348,6 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb, unsigned int cpu = (unsigned long)hcpu; switch (action) { - case CPU_ONLINE: - case CPU_ONLINE_FROZEN: - cpufreq_update_policy(cpu); - break; case CPU_DOWN_PREPARE: case CPU_DOWN_PREPARE_FROZEN: cpufreq_stats_free_sysfs(cpu); @@ -390,8 +386,6 @@ static int __init cpufreq_stats_init(void) return ret; register_hotcpu_notifier(&cpufreq_stat_cpu_notifier); - for_each_online_cpu(cpu) - cpufreq_update_policy(cpu); ret = cpufreq_register_notifier(¬ifier_trans_block, CPUFREQ_TRANSITION_NOTIFIER);
The call to cpufreq_update_policy() is placed in the CPU hotplug callback of cpufreq_stats, which has a higher priority than the CPU hotplug callback of cpufreq-core. As a result, during CPU_ONLINE/CPU_ONLINE_FROZEN, we end up calling cpufreq_update_policy() *before* calling cpufreq_add_dev() ! And for uninitialized CPUs, it just returns silently, not doing anything. To add to it, cpufreq_stats is not even the right place to call cpufreq_update_policy() to begin with. The cpufreq core ought to handle this in its own callback, from an elegance/relevance perspective. So move the invocation of cpufreq_update_policy() to cpufreq_cpu_callback, and place it *after* cpufreq_add_dev(). Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> --- drivers/cpufreq/cpufreq.c | 1 + drivers/cpufreq/cpufreq_stats.c | 6 ------ 2 files changed, 1 insertion(+), 6 deletions(-) -- 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