1
0
mirror of https://github.com/ARM-software/workload-automation.git synced 2025-02-20 20:09:11 +00:00

doc: Update RebootPolicy and ExectionOrder information

This commit is contained in:
Marc Bonnici 2018-05-22 17:54:48 +01:00 committed by setrofim
parent dc41af1f3f
commit cacc4dec8b
3 changed files with 11 additions and 4 deletions

View File

@ -180,7 +180,7 @@ execution, so all subsequent iterations will also be affected unless they
explicitly change the parameter (in the example above, performance governor will
also be used for ``memcpy`` and ``cyclictest``. There are two ways around this:
either set ``reboot_policy`` WA setting (see :ref:`configuration-specification`
section) such that the device gets rebooted between spec executions, thus being
section) such that the device gets rebooted between job executions, thus being
returned to its initial state, or set the default runtime parameter values in
the ``config`` section of the agenda so that they get set for every spec that
doesn't explicitly override them.

View File

@ -293,9 +293,9 @@ Reboot Policy
^^^^^^^^^^^^^
This indicates when during WA execution the device will be rebooted. By default
this is set to ``as_needed``, indicating that WA will not reboot the device. Please
see ``reboot_policy`` documentation in :ref:`configuration-specification` for
more details.
this is set to ``as_needed``, indicating that WA will only reboot the device if
it becomes unresponsive. Please see ``reboot_policy`` documentation in
:ref:`configuration-specification` for more details.
Execution Order
^^^^^^^^^^^^^^^

View File

@ -81,6 +81,13 @@ the new parameter names should be preferred:
whether a package on the target or the host should have priority when
searching for a suitable package.
- The execution order ``by_spec`` is now called ``by_workload`` for clarity of
purpose. For more information please see :ref:`configuration-specification`.
- The ``by_spec`` reboot policy has been removed as this is no longer relevant
and the ``each_iteration`` reboot policy has been renamed to ``each_job``,
please see :ref:`configuration-specification` for more information.
Individual workload parameters have been attempted to be standardized for the
more common operations e.g.: