Add cpustates output processor. This is more-or-less a port of the
cpustates processor from WA, however there are some differences:
- Idle states are now tracked individually per-CPU. This will fix
processing traces from targets that have different number of idle
states on different clusters.
- Simplify the parameter list for report_power_stats:
- Replace paths to individual report files with a path to a single
directory. A subdirectory will be created under it which will
contain all the reports.
- Replace the individual bits bits of information about CPUs (core
names, idle states, etc) with a list of CpuInfo objects.
- Clean up and simplify the code a bit:
- Make all reports mandatory -- the marginal cost of generating
an additional report is minimal compared to tracking power states
in the first place.
- Standardize the interface for Reporters and Reports.
- Rename some of the reports to something a bit more meaningful.
- The stand-alone command line interface is not ported for now, as it
is now possible to run this offline on existing results using
"wa process".
Move the check_for_markers and events parameters from parser() to
__init__(). These parameters control the behavior of the parser, and do
not relate to a particular trace file, so it makes more sense to have
them there.
Running additional processors will generate new metrics and artifacts.
Update the serialized metadata with the new artifacts/metrics after
running all processors.
Extracting trace and pulling the trace file from the target can take a
relatively long time, as the trace file can be tens, and even hundreds,
of MB. Add an info-level log message to inform the user why WA execution
appears to have paused for a few seconds.
- Have the job manage the indent of each of its stages
- Switch output_processor to using indentcontext
- Move the "Configuring augmentations" log line into Job -- the
rest of the stages are logged there, but this was done by the
Executor for some reason.
On the latest version of Sphinx the way we were doing API generation
caused issues. Due to the structure/formatting of our code base the
output was not very useful anyway so remove the automatic generation
with the aim to manually document the relevant API in the future.
Add hostid entry, as reported by busybox's hostid applet, to TargetInfo.
This is intended to be a "unique 32-bit identifier for the current
machine". In practice, it may not be set, or may be generated from
something like an IP address, so may not be unique. However, if set, it
is still likely to be more unique than kernel/os version so may be worth
recording.
Replace Target.cpuinfo, which contained parsed contents of
/proc/cpuinfo, with a list of more comprehensive CpuInfo objects which
include cpufreq and cpuidle information as well.
- Use indentcontext inside initialize_run to make sure log level
is dedented on error.
- Ensure Executor postamble always runs, event if runner errors.
- Fix format_duration() to handle sub-second timedeltas.
Add a function to return WA version suffixed with the commit hash for
current HEAD. This only works if WA was deployed via
python setup.py develop
otherwise, the output is identical to get_wa_version().
When scanning modules for plugins, only consider classes defined in that
module, but not those imported into it. This will prevent log output
being polluted with repeated "Skipping..." messages for imported plugin
bases.
Ensure buffered records are indented properly by saving the indent level
at the time the record was generated as part of the record, and
preferring that over the current indent level inside LineFormatter.
Move the logging of the WA version and command line used to invoke it
from run command into main() inside entrypoint. That way, these will be
the first entries in the log file, now that early log records are no
longer lost.
Buffer early log records until a log file becomes available, flush
records to said file afterwards. This ensures that early log output,
which, among other things, contains plugin discovery logging, is not
lost. Buffer capacity is configurable via an environment variable.
If more then one of augmentation entries ("augmentations",
"instrumenatation", "output_processors") is specified in the same
config they were being merged into a single entry.
This can cause issues with '~~' (drop everything glyph) being "resolved"
during this merge and therefore not actually used to drop all previous
augmentations.
Union'ing, instead of merging, configs at the same level avoids that.
Note that this is semantically correct, as we're not enforcing
precedence at the same level of config, so merge semantics do not apply.
Add support for "~~" special value that indicates that, when merging
into another set, all values from that set should in fact be dropped.
Apart from the unique merge semantics, "~~" just like any other "~"
value.
- The merge_with and merge_into implementation was reversed. Fix this, so that
it is implemented correctly, i.e. that
a.merge_with(b) === merge(a, b)
a.merge_into(b) === merge(b, a)
- Ensure that in case of merge_into(), a toggle_set is always returned.
Delay the split of augmentations into instruments and output processors
until they are actually being accessed; keep them as a single set until
then. This makes tracking of merges from various configurations sources
easier