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.
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).
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.
(linux|android)_gem5 devices were being described as having gem5
platforms but standard linux/android connections. This commit fixes this
by making sure that the gem5 connection is used.
Seem I cherry-picked the geekbench workload from my WIP branch
without testing properly, and missed a fixup commit. Here's the
content of that commit, which fixes some missing updates from WA2 ->
WA3 APIs.
Devlib's ACME instrument uses iio-capture under the hood, which can
only capture data from one IIO device at a time. Devlib's instrument
API expects to produce a single CSV file for the Instrument, with a
single axis of sample timestamps. These two things cannot be
correctly reconciled without changing the devlib Instrument API -
get_data would need to be able to return two distinct sets of data.
Instead, where required WA will instantiate the ACME instrument
multiple times (once for each IIO device), producing two separate CSV
files. Aggregated energy info (as opposed to timestamped samples of
energy data) _can_ be meaningfully combined from multiple IIO
devices, so the derived stats are summed.
This requires altering the internal API of the energy_measurement
module - rather than a single instrument the super-instrument now has
a dictionary mapping 'device' keys (this is really an arbitrary key,
but I think that 'device' is a justifiable metaphor for whatever
might separate multiple instruments, plus it is the terminology used
by IIO/ACME) to Instrument objects. Existing instruments simply
return a dict with a single entry, with None as the key.
It may in future be possible to solve this problem in devlib's ACME
instrument by avoiding the use of the iio-capture tool. In that case,
it should be possible to basically revert this patch and get the
required funcitonality from devlib.
Runtime param names from config were matched against names available on
for the target using an overly-loose regex that resulted in the wrong
config point being returned.
Use caseless_string matching instead.
As paramters defined by energy_measurement instrument backends were not
used in instantiating the backends, but the underlying devlib
instrument, the values did not undergo the usual Plugin parameter
setting perocedure. In particuar, type conversion would not take place.
Make sure backend parameters are validated properly by setting them on
an obj_dict before passing them to the devlib instrument.
