If we switch the 'schedutil' cpufreq governor on, the 'time_in_state'
data becomes useless. And since cpufreq governors can be switched at any
time, we might as well make it possible to support transitioning between
governors without any bogus data appearing in our charts.
Before this commit, switching to 'schedutil' results in zeroed values,
and switching back to any other governor causes a huge spike datapoint
in the timeline.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
There were two major problems with this module:
- The 'cpuN' names weren't accurate. The 'self.paths.sort()' was trying
to compensate for os.walk() enumerating the CPUs out of order (as any
directory enumeration will do). Unfortunately the sort() function is
alphabetical, so it would result in a list of paths like this:
[
'/sys/.../cpu0/...'
'/sys/.../cpu1/...'
'/sys/.../cpu11/...'
'/sys/.../cpu12/...'
...
]
So the chart for cpu2 would actually map to cpu11's stats.
This can be corrected by extracting the 'cpuN' value that's already
inside the path anyway.
- The scaling_cur_freq value is an instantaneous value. It only
represents the current processor P-state at the time it was read, and
doesn't account for the other 999ms that netdata wasn't looking at the
value.
This can be corrected by using data from cpufreq_stats, which includes
P-state residency statistics. Note that the values in cpufreq_stats
aren't always valid (e.g. if the cpufreq governor is set to
'schedutil', the statistic files exist but are are empty), so we can
just fall back to the inaccurate scaling_cur_freq method if necessary.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
