Messages in this thread | | | Date | Wed, 16 Sep 2020 11:26:41 +0530 | From | Viresh Kumar <> | Subject | Re: [PATCH 1/4] cpufreq: stats: Defer stats update to cpufreq_stats_record_transition() |
| |
On 15-09-20, 11:04, Lukasz Luba wrote: > Hi Viresh, > > On 9/2/20 8:24 AM, Viresh Kumar wrote: > > In order to prepare for lock-less stats update, add support to defer any > > updates to it until cpufreq_stats_record_transition() is called. > > > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > --- > > drivers/cpufreq/cpufreq_stats.c | 75 ++++++++++++++++++++++++--------- > > 1 file changed, 56 insertions(+), 19 deletions(-) > > > > diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c > > index 94d959a8e954..fdf9e8556a49 100644 > > --- a/drivers/cpufreq/cpufreq_stats.c > > +++ b/drivers/cpufreq/cpufreq_stats.c > > @@ -22,17 +22,22 @@ struct cpufreq_stats { > > Would it be possible to move this structure in the > linux/cpufreq.h header? Any subsystem could have access to it, > like to the cpuidle stats.
Hmm, I am not sure why we should be doing it. In case of cpuidle many parts of the kernel are playing with cpuidle code, like drivers/idle/, drivers/cpuidle, etc.
Something should land in include/ only if you want others to use it, but in case of cpufreq no one should be using cpufreq stats.
So unless you have a real case where that might be beneficial, I am going to keep it as is.
> Apart from that (and the comment regarding the 'atomic_t' field) > I don't see any issues.
Thanks.
-- viresh
| |