During my time working with the rt-app cpufreq efficiency test I came across a few rough edges. Patches 1-4 address those.
Patch 5 essentially rewrites the test.sh script. Prior to this patch test.sh takes a single governor and workload specification (duty cycle). It runs the workload with this governor as well as the perf and power governors then calculates efficiency. If we want to profile multiple governors, using this script would result in running the workload under the perf and power governors multiple times. You could run dvfs.sh script directly in which case the efficiency must be manually calculated.
Patch 5 adds support to test.sh to accept a test specification file with the -f parameter. A test specification file specifies the CPU to run the tests on, the governors to test (excluding the perf and power governors), and the workloads to test. It looks like this:
1 ondemand interactive schedutil 1 100 100 10 1000 10 1 10 1000
The workloads are specified as: <busy time @fmax in ms> <period length in ms> <# of loops>
The results are output in a text-formatted table suitable for email.
CPU frequency residency is also tracked as part of patch 5. At the end of the testing the residencies for each test for a given governor are printed in a table. This depends on cpufreq stats being enabled on the platform.
The test.sh script continues to accept arguments as it did previously, i.e. it will accept a single governor and workload on the command line.
Steve Muckle (5): rt-app: fix cpufreq test loops rt-app: change default sched class for dvfs test to SCHED_OTHER rt-app: tidy up cpufreq efficiency README rt-app: save and restore governor in dvfs.sh cpufreq efficency test rt-app: rework cpufreq efficiency script
doc/examples/cpufreq_governor_efficiency/README | 85 ++++--- doc/examples/cpufreq_governor_efficiency/dvfs.json | 4 +- doc/examples/cpufreq_governor_efficiency/dvfs.sh | 13 +- doc/examples/cpufreq_governor_efficiency/test.sh | 246 ++++++++++++++------- 4 files changed, 238 insertions(+), 110 deletions(-)