sascha/workload-automation
1
0
Fork 0
mirror of https://github.com/ARM-software/workload-automation.git synced 2025-01-18 20:11:20 +00:00
Code Issues Releases Wiki Activity

doc: Update sections example.

Browse Source 
Modify documention and example to better explain sections
This commit is contained in:
Marc Bonnici 2018-05-16 10:50:58 +01:00 committed by setrofim
parent b7c70aabae
commit 5c6cc87105
1 changed files with 11 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
doc/source/how_tos/users/agenda.rst
View File

@ -437,20 +437,19 @@ Sections
-------- --------
It is a common requirement to be able to run the same set of workloads under It is a common requirement to be able to run the same set of workloads under
different device configurations. E.g. you may want to investigate impact of different device configurations. E.g. you may want to investigate the impact of
changing a particular setting to different values on the benchmark scores, or to changing a particular setting to different values on the benchmark scores, or to
quantify the impact of enabling a particular feature in the kernel. WA allows quantify the impact of enabling a particular feature in the kernel. WA allows
this by defining "sections" of configuration with an agenda. this by defining "sections" of configuration with an agenda.
For example, suppose what we really want, is to measure the impact of using For example, suppose that we want to measure the impact of using 3 different
interactive cpufreq governor vs the performance governor on the three cpufreq governors on 2 benchmarks. We could create 6 separate workload specs
benchmarks. We could create another three workload spec entries similar to the and set the governor runtime parameter for each entry. However, this
ones we already have and change the sysfile value being set to "interactive". introduces a lot of duplication; and what if we want to change spec
However, this introduces a lot of duplication; and what if we want to change configuration? We would have to change it in multiple places, running the risk
spec configuration? We would have to change it in multiple places, running the of forgetting one.
risk of forgetting one.
A better way is to keep the three workload specs and define a section for each A better way is to keep the two workload specs and define a section for each
governor: governor:
.. code-block:: yaml .. code-block:: yaml
@ -471,6 +470,9 @@ governor:
- id: inter - id: inter
runtime_params: runtime_params:
cpu0_governor: interactive cpu0_governor: interactive
- id: sched
runtime_params:
cpu0_governor: sched
workloads: workloads:
- id: 01_dhry - id: 01_dhry
name: dhrystone name: dhrystone