README-BENCH

  1This is cpufreq-bench, a microbenchmark for the cpufreq framework.
  2
  3Purpose
  4=======
  5
  6What is this benchmark for:
  7  - Identify worst case performance loss when doing dynamic frequency
  8    scaling using Linux kernel governors
  9  - Identify average reaction time of a governor to CPU load changes
 10  - (Stress) Testing whether a cpufreq low level driver or governor works
 11    as expected
 12  - Identify cpufreq related performance regressions between kernels
 13  - Possibly Real time priority testing? -> what happens if there are
 14    processes with a higher prio than the governor's kernel thread
 15  - ...
 16
 17What this benchmark does *not* cover:
 18  - Power saving related regressions (In fact as better the performance
 19    throughput is, the worse the power savings will be, but the first should
 20    mostly count more...)
 21  - Real world (workloads)
 22
 23
 24Description
 25===========
 26
 27cpufreq-bench helps to test the condition of a given cpufreq governor.
 28For that purpose, it compares the performance governor to a configured
 29powersave module.
 30
 31
 32How it works
 33============
 34You can specify load (100% CPU load) and sleep (0% CPU load) times in us which
 35will be run X time in a row (cycles):
 36
 37         sleep=25000
 38         load=25000
 39         cycles=20
 40
 41This part of the configuration file will create 25ms load/sleep turns,
 42repeated 20 times.
 43
 44Adding this:
 45         sleep_step=25000
 46         load_step=25000
 47         rounds=5
 48Will increase load and sleep time by 25ms 5 times.
 49Together you get following test:
 5025ms  load/sleep time repeated 20 times (cycles).
 5150ms  load/sleep time repeated 20 times (cycles).
 52..
 53100ms load/sleep time repeated 20 times (cycles).
 54
 55First it is calibrated how long a specific CPU intensive calculation
 56takes on this machine and needs to be run in a loop using the performance
 57governor.
 58Then the above test runs are processed using the performance governor
 59and the governor to test. The time the calculation really needed
 60with the dynamic freq scaling governor is compared with the time needed
 61on full performance and you get the overall performance loss.
 62
 63
 64Example of expected results with ondemand governor:
 65
 66This shows expected results of the first two test run rounds from
 67above config, you there have:
 68
 69100% CPU load (load) | 0 % CPU load (sleep)  | round
 70   25 ms             |    25 ms              |   1
 71   50 ms             |    50 ms              |   2
 72
 73For example if ondemand governor is configured to have a 50ms
 74sampling rate you get:
 75
 76In round 1, ondemand should have rather static 50% load and probably
 77won't ever switch up (as long as up_threshold is above).
 78
 79In round 2, if the ondemand sampling times exactly match the load/sleep
 80trigger of the cpufreq-bench, you will see no performance loss (compare with
 81below possible ondemand sample kick ins (1)):
 82
 83But if ondemand always kicks in in the middle of the load sleep cycles, it
 84will always see 50% loads and you get worst performance impact never
 85switching up (compare with below possible ondemand sample kick ins (2))::
 86
 87      50     50   50   50ms ->time
 88load -----|     |-----|     |-----|     |-----|
 89          |     |     |     |     |     |     |
 90sleep     |-----|     |-----|     |-----|     |----
 91    |-----|-----|-----|-----|-----|-----|-----|----  ondemand sampling (1)
 92         100    0    100    0    100    0    100     load seen by ondemand(%)
 93       |-----|-----|-----|-----|-----|-----|-----|--   ondemand sampling (2)
 94      50     50    50    50    50    50    50        load seen by ondemand(%)
 95
 96You can easily test all kind of load/sleep times and check whether your
 97governor in average behaves as expected.
 98
 99
100ToDo
101====
102
103Provide a gnuplot utility script for easy generation of plots to present
104the outcome nicely.
105
106
107cpufreq-bench Command Usage
108===========================
109-l, --load=<long int>           initial load time in us
110-s, --sleep=<long int>          initial sleep time in us
111-x, --load-step=<long int>      time to be added to load time, in us
112-y, --sleep-step=<long int>     time to be added to sleep time, in us
113-c, --cpu=<unsigned int>        CPU Number to use, starting at 0
114-p, --prio=<priority>           scheduler priority, HIGH, LOW or DEFAULT
115-g, --governor=<governor>       cpufreq governor to test
116-n, --cycles=<int>              load/sleep cycles to get an average value to compare
117-r, --rounds<int>               load/sleep rounds
118-f, --file=<configfile>         config file to use
119-o, --output=<dir>              output dir, must exist
120-v, --verbose                   verbose output on/off
121
122Due to the high priority, the application may not be responsible for some time.
123After the benchmark, the logfile is saved in OUTPUTDIR/benchmark_TIMESTAMP.log
124