A label may include ``{<param_name>}`` where <param_name> is any valid
workload, boot or runtime parameter that the workload may take. The
generated job will then substitute in the value of that parameter that
was taken.
More than one parameter may be identified (within separate sets of
``{}``) within a single label, and these may be alongside normal text
similar to python replacement fields.
Sweeps are handled by one of three handlers, ``autofreq``, ``range`` and
``autoparam``. ``range`` allows the user to manually specify values for
a parameter in the agenda; ``autofreq`` allows cpu frequencies to be
swept through, and autoparam allows other parameters to be swept
through.
autoparam requries the parameter to have ``allowed_values`` specified,
and the sweep specification must supply the plugin name and parameter
name as:
``
sweep(autoparam):
param: <param name>
plugin: <plugin name>
``
autofreq can be used with an empty value:
``
sweep(autofreq):
``
to sweep through all values of ``frequency`` by default, although if
``plugin`` is specified, other parameters within cpufreq can be swept
through:
``
sweep(autofreq):
param: cpu0_frequency
``
For either of the above 'automatic' sweeps, a minimum and/or maximum can
be specified to limit the values generated in the sweep:
``
sweep(autofreq):
param: cpu0_frequency
min: 1000000
max: 1700000
``
``range`` sweeps support two specification syntaxes: one for manual
specification of a list, and another for a range of values. These sweeps
only accept the plugin name as a parameter:
``
sweep(range):
threads: [1, 3, 5, 7]
``
or
``
sweep(range):
threads: 1-8,2
# start-stop[,step]
``
These both produce the same result. step is optional and defaults to 1.
Any sweep specified in a workload entry is equivalent to manually
specifying individual workload entries, each with one of the possible
values of the sweep.
Sweeps specified in sections will create the equivalent of a section
group, each section in that group with one of the sweep values. When the
group name is specified, the 'expanded' section entry will maintain that
group name, otherwise will generate its own.
If multiple sweeps are specified in one entry, then this will be
expanded to one entry for every combination of values of each sweep.
Add a global configuration parameter ``bail_on_job_failure`` that
allows all remaining jobs in a run to be skipped should a job fail its
initial execution and its retries. This is by default disabled.
Provide warning to user when attempting to set a depreciated
parameter instead of during validation and only raise the warning
if a value has been explicitly provided.
Allow specifying a ConfigutationPoint is deprecated. This means that any
supplied configuration will not be used however execution will continue
with a warning displayed to the user.
If no jobs have been generated that are available for running then WA
will crash when trying to access the job queue. Add an explicit check to
ensure that a sensible error is raised in this case, for example if
attempting to run a specific job ID that is not found.
Now allows for specifying a `group` value for each section which will
cross product the sections within that group with the sections in each
other group. Additionally classifiers will automatically be added to
each job spec with the relevant group information.
Ensure that a plug-ins config entry is converted to an identifier before being
stored in the PluginCache so that the relevant configuration can be
retrieved appropriately. For example this allows for both 'trace-cmd' and
'trace_cmd' to be used as config entries to provide configuration for the
'trace-cmd' plugin.
- Add copyright headers to files that did not already have them
- Update the year to the last year the file was modified in files with
existing headers.
- expose pluginloader's resolve_alias in plugin_cache (it's supposed
to be a transparent proxy for pluginloader).
- resolve aliases inside _set_plugin_defaults() to make sure the
correct defaults are used when creating job specs.
Rename the parameter to be clearer on the effect of the policy, as this
will cause WA to reset the device for each new job it runs regardless of
the iteration number.
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.
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
If WA is ran without any workloads being specified, previously an index
error was thrown, now check that at least one global workload has been
specified and if not, provide a more helpful error message.
