Now that we add an event when logging errors, we need to avoid passing an
exception object directly to the logger. Otherwise we end up adding the
unserializable Exception object to the events list, which causes an error when
trying to write the output.
This maintains the default behaviour of bailing out immediately if any workload
fails in initialize(), but adds a setting, bail_on_init_failure, to change this
behaviour optionally. This can be useful where WA is being used more as a batch
processor.
Changes to the Status enum introduced by 31a535b5 and a9959550 broke
ran Jobs summary status at the end of the run. This fixes it so that the
total number of jobs and individual status counts are reported
correctly.
The generic "frequency" runtime parameter was only being set when there
are common frequences between avialable cores. It should always be set,
even if there are no frequencies in common, as it still valid to use it
with special values "min" and "max", in which case it should resolve
correctly to the appropriate frequencies.
Set context for the loggers of the Runner, the workloads and the
installed instruments and processors. Errors/warnings logged by these
entities will be automatically added as events.
Add ContextLogger wich extends logging.Logger's warning and error
methods to automatically add the message to the context's events (if a
context has been provided).
This enables you to do things like:
global:
runtime_parameters:
airplane_mode: true # This improves repeatability of energy measurements
workloads:
- name: foo
- name: bar
- name: geekbench
runtime_parameters:
airplane_mode: false # Geekbench requires network, and we don't care
# about energy for that workload anyway
For some reason I didn't look at the WA2 instrument until afer I
wrote this, so it's different in how it handles 'before/after'
quantities (which I called 'momentary' in the code) - instead of
adding a 'mean' it just adds two separate metrics: one for before and
one for after. Personally I think this is more useful (esp. for
temperature) but if necessary I can revert to the old behaviour.
This also doesn't add the helpful classifier telling you the hwmon
device, because we don't have immediate access to that info from the
devlib Instrument. If necessary I'm sure it could be added later.
Furthermore it doesn't have a parameter to filter the sensors, just
collects from them all.
Where backends have the capability to collect from multiple devlib
Instruments, EnergyMeasurement currently appends 'device' keys to the
names of metrics reported by those Instruments. Where multiple
Instruments are indeed used, it then sums up equivalent metrics to
produce the 'normal' metric without the 'device' keys
appended.
E.g. If you have two ACME 'devices' enabled you will get something
like
'device_total_energy_iio:device0' and
'device_total_energy_iio:device1', which will be summed to produce
'device_total_energy'.
However when only one Instrument is actually instantiated, this is
not needed and not done. Therefore just directly produce the metric
with the name originally given by devlib (i.e. in the example,
'device_total_energy').
Fully matching an APK resource requires the file to be present locally,
so that its metadata can be queries. HTTP getter was matching against a
remote path so the match was failing.
The matching now happens in two stages == first partial path-only
matches are established. Secondly, all partial matches are downloaded
and final match occurs against downloaded files.
This method is used to partially match a resource; its implementation
cannot rely on the resource file actually being present and must match
against the specified path alone.
match() implementation now defaults to match_path(), as for most
resource types, the path is sufficient to uniquely match a resource.
Devlib's get_data API can return None when something goes wrong -
this currently results in us attempting to add a non-existent
artifact.
To avoid this confusion, check and use the return value from
get_data, instead of assuming that it will write data to its
'outfile' parameter.
Currently if you get confused and write a config with something like:
energy_measurement:
acme_cape
Then you get an error when we try to 'iteritems' on the value
'acme_cape'. Instead, explicitly check for this case.
- Fix start/stop methods of sysfile_getter, which where still using the
WA2 mechanic of prefixing "slow_" to the name to indicate priority,
and consequently weren't being invoked.
- Call super inside cpufreq's valide(() to make sure tempfs path is set.
- Make sure TargetManager.finalize() actually gets called at the end
of the run.
- Overrule the "diconnect" parameter behavior for gem5 and make sure it
always disconnects. This necessary for stats to be generated properly.
devlib's CGgroups module logs things at INFO level. The information it
logs is too detailed for what WA considers "INFO", and should be logged
at DEBUG level instead.
Gem5Platform requires a host output directory as one if it's
instantiation parameters. This is not something we want to expose a
configuration parameter to the user, as for WA, the standard output
directory ought to be used.
Up to this point, WA's target instatiation process assumed that all
parameters came from the user, and there was no way for WA itself to set
them. This commit adds extra_platform_parms argument to
instantiate_target, to remedi this.
extra_platform_parms is then used to set the host output directory for
gem5 appropriately.
