When collecting ftrace events, the instrument will insert frequencies
into the trace to make it possible reconstruct power states when there
were no frequency transitions during the measured period.
The format in which frequencies are inserted is different in devlib.
Since post-processing scripts may be run on traces collected by devlib
as well as WA, it needs to support both formats.
When running the stand-alone cpustates script and specifying a timeline
file (which causes the corresponding reporter to be enabled), a
timeline report is generated in addition to the usual cpustates and
parallelism reports.
Up to this point, the main() of the stand-alone script was expecting
exactly two reports and so it crashing when running with the timeline
option. This commit fixes this case.
cpustates can now handle the lack of a start marker in three ways:
- try: If the start marker is present only the correct section of the trace
will be used, if its not the whole trace will be used.
- error: An error will be raised if the start marker is missing
- ignore: The markers are ignored and the whole trace is always used.
If an exception is raised inside a generator it cannot be continued.
To get around this exceptions are now caught and later output via the
logger.
Also added logger setup when running cpustates as a standalone script
Previously, only reports that were generated were returned. With this
commit, there will be an entry for each active reporter in the returned
list. If a reporter did not produce a valid report, the entry will be
None.
This ensures consistent output, even if a run time issue causes a
reporter not to produce a report (e.g. if cpufreq events were not
enabled).
Fixed error in percentage when frequency is 'None'. Now default to 0 in these cases
cpu_utilisation is now a separate parameter in cpustate. Now generates a floating point number representing the utilisation based on the maximum frequency of the capture. No longer performs averaging of values, this can be done as a post-processing step
cpu utilisation now based on the max cpu freq per core, not max captured freq overall
cpustate result processor generates a view of the cpu subsystem power
state during execution of a workload from cpu_idle and cpu_frequency
ftraces. There exists a period before the first events in those
categories are seen where the state of the cpu subsystem is (partially)
unknown and it is reported as such by the result processor.
Unknown state usually exists for a relatively short period of time and
is generally not a big deal. For certain kinds of workloads, however, it
may constitude a significant protion of the trace.
Changes in this commit attempt to deal with this by a) reading starting
cpu frequencies and writing them into the trace, and b) nudging each
core to bring it out of idle; this happens before the start marker, so
that the system state between the markers should be completely known.
