Messages in this thread | | | Subject | Re: [PATCH V2 1/4] cpufreq: stats: Defer stats update to cpufreq_stats_record_transition() | From | Lukasz Luba <> | Date | Fri, 25 Sep 2020 09:10:36 +0100 |
| |
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.
| |