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.
Some workloads, such as Geekbench, may phone home and report data about the
device they are running on. This poses a risk for users that are testing on
unreleased or otherwise confidential devices - perhaps they use a standard
agenda to run a large battery of tests, in which case they may forget to disable
these dangerous workloads.
This provides a mechanism to prevent running those workloads from running by
setting allow_phone_home=False in the user configuration.
Currently if your config contains
typo_for_a_global_alias: 1
You will get an error where we try to call 'iteritems' on the value 1. This
commit re-orders the checks so that you instead get an error for the
unrecognised 'typo_for_a_global_alias'.
Differences from original:
- Standard renaming and rearrangement of imports
- UiAutomation.java now uses the setup() and runWorkload() phases which weren't
present before.
Due to the nature of modern Android devices, in order to usefully
interpret the power* events, you more and more often need to know the
kernel's view of temperature too. Therefore I think enabling the
thermal event group by default makes sense.
- Add "activity" property to PackageManager exposing the underlying
apk_info attribute.
- Add "view" class attribute to ApkWorkload, initialized to None
- If "view" is not set for a particular workload, set a default based on
the package and activity of the underlying workload.
- Ensure that CLOCK_MONOTONIC is used for all timestamps, so that the
timestamps collected by revent and those reported in the struct
input_event wouild match.
- Do not attempt to free events array inside fini_revent_recroding() if
no events have been recorded.
- Add missing \n in some debug messages.
- Add end of recording debug message.
- Make sure start/end timestamps are properly adjusted when there are
zero events.
- Rename adjust_event_times --> adjust_timestamps, as the latter better
fits its current function.
- Add a couple of debug messages.
DerivedMeasurements in devlib was changed to return DerivedMetrics
instead of Measurements. The former do not have "channel" attribute, so
just pass its name to WA's metrics.
If an error occurs in a ManagedCallback that is invoked outside of a
job, re-raise rather than attempting to update the status of the
non-existent job.
