Re: [PATCH V2 1/4] cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()

[Lukasz Luba]

On 9/25/20 7:09 AM, Viresh Kumar wrote:
> On 24-09-20, 17:10, Lukasz Luba wrote:
> > Because of supporting this reset file, the code is going to be a bit
> > complex
>
> I will say not very straight forward, but it isn't complex as well.
>
> > and also visited from the scheduler. I don't know if the
> > config for stats is enabled for production kernels but if yes,
> > then forcing all to keep that reset code might be too much.
> > For the engineering kernel version is OK.
>
> I am not sure either if they are enabled for production kernels, but even if it
> then also this code won't hit performance.
>
> > I would say for most normal checks these sysfs stats are very useful.
> > If there is a need for investigation like you described, the trace
> > event is there, just have to be enabled. Tools like LISA would
> > help with parsing the trace and mapping to some plots or even
> > merging with scheduler context.
>
> Right, but stats is much easier in my opinion and providing this reset
> functionality does make it easier to track. And that it is already there now.
>
> >  From time to time some engineers are asking why the stats
> > don't show the values (missing fast-switch tracking). I think
> > they are interested in a simple use case, otherwise they would use the
> > tracing.
>
> Right and I completely agree with that and so this patchset. I think there
> aren't any serious race conditions here that would make things bad for anyone
> and that this patchset will eventually get in after a little rearrangement.

Fair enough, let see the final implementation. We can check it with perf
the speculative exec and cache util.