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
> > ---
> > 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
Re: [PATCH 1/4] cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()
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
---
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.
Apart from that (and the comment regarding the 'atomic_t' field)
I don't see any issues.
Regards,
Lukasz
Re: [PATCH 1/4] cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()
On Fri, Sep 11, 2020 at 1:36 PM Viresh Kumar wrote: > > On 11-09-20, 12:11, pet...@infradead.org wrote: > > On Wed, Sep 02, 2020 at 12:54:41PM +0530, Viresh Kumar wrote: > > > + atomic_t reset_pending; > > > > > + atomic_set(>reset_pending, 0); > > > + if (atomic_read(>reset_pending)) > > > + bool pending = atomic_read(>reset_pending); > > > + atomic_set(>reset_pending, 1); > > > + bool pending = atomic_read(>reset_pending); > > > + if (atomic_read(>reset_pending)) > > > > What do you think atomic_t is doing for you? > > I was trying to avoid races while two writes are going in parallel, > but obviously as this isn't a RMW operation, it won't result in > anything for me. > > Maybe what I should be doing is just READ_ONCE()/WRITE_ONCE()? So the > other side doesn't see any intermediate value that was never meant to > be set/read ? If the value in question is a pointer or an int (or equivalent), READ_ONCE()/WRITE_ONCE() should be sufficient, and should be used at least as a matter of annotation of the sensitive code IMO. IIRC, atomic_set() and atomic_read() are pretty much the same as WRITE_ONCE() and READ_ONCE(), respectively, anyway. Cheers!
Re: [PATCH 1/4] cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()
On 11-09-20, 12:11, pet...@infradead.org wrote: > On Wed, Sep 02, 2020 at 12:54:41PM +0530, Viresh Kumar wrote: > > + atomic_t reset_pending; > > > + atomic_set(>reset_pending, 0); > > + if (atomic_read(>reset_pending)) > > + bool pending = atomic_read(>reset_pending); > > + atomic_set(>reset_pending, 1); > > + bool pending = atomic_read(>reset_pending); > > + if (atomic_read(>reset_pending)) > > What do you think atomic_t is doing for you? I was trying to avoid races while two writes are going in parallel, but obviously as this isn't a RMW operation, it won't result in anything for me. Maybe what I should be doing is just READ_ONCE()/WRITE_ONCE()? So the other side doesn't see any intermediate value that was never meant to be set/read ? -- viresh
Re: [PATCH 1/4] cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()
On Wed, Sep 02, 2020 at 12:54:41PM +0530, Viresh Kumar wrote: > + atomic_t reset_pending; > + atomic_set(>reset_pending, 0); > + if (atomic_read(>reset_pending)) > + bool pending = atomic_read(>reset_pending); > + atomic_set(>reset_pending, 1); > + bool pending = atomic_read(>reset_pending); > + if (atomic_read(>reset_pending)) What do you think atomic_t is doing for you?
