Dominik Brodowski | 7fe2f63 | 2011-03-30 16:30:11 +0200 | [diff] [blame] | 1 | This is cpufreq-bench, a microbenchmark for the cpufreq framework. |
| 2 | |
| 3 | Purpose |
| 4 | ======= |
| 5 | |
| 6 | What 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 | |
| 17 | What 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 | |
| 24 | Description |
| 25 | =========== |
| 26 | |
| 27 | cpufreq-bench helps to test the condition of a given cpufreq governor. |
| 28 | For that purpose, it compares the performance governor to a configured |
| 29 | powersave module. |
| 30 | |
| 31 | |
| 32 | How it works |
| 33 | ============ |
| 34 | You can specify load (100% CPU load) and sleep (0% CPU load) times in us which |
| 35 | will be run X time in a row (cycles): |
| 36 | |
| 37 | sleep=25000 |
| 38 | load=25000 |
| 39 | cycles=20 |
| 40 | |
| 41 | This part of the configuration file will create 25ms load/sleep turns, |
| 42 | repeated 20 times. |
| 43 | |
| 44 | Adding this: |
| 45 | sleep_step=25000 |
| 46 | load_step=25000 |
| 47 | rounds=5 |
| 48 | Will increase load and sleep time by 25ms 5 times. |
| 49 | Together you get following test: |
| 50 | 25ms load/sleep time repeated 20 times (cycles). |
| 51 | 50ms load/sleep time repeated 20 times (cycles). |
| 52 | .. |
| 53 | 100ms load/sleep time repeated 20 times (cycles). |
| 54 | |
| 55 | First it is calibrated how long a specific CPU intensive calculation |
| 56 | takes on this machine and needs to be run in a loop using the performance |
| 57 | governor. |
| 58 | Then the above test runs are processed using the performance governor |
| 59 | and the governor to test. The time the calculation really needed |
| 60 | with the dynamic freq scaling governor is compared with the time needed |
| 61 | on full performance and you get the overall performance loss. |
| 62 | |
| 63 | |
| 64 | Example of expected results with ondemand governor: |
| 65 | |
| 66 | This shows expected results of the first two test run rounds from |
| 67 | above config, you there have: |
| 68 | |
| 69 | 100% CPU load (load) | 0 % CPU load (sleep) | round |
| 70 | 25 ms | 25 ms | 1 |
| 71 | 50 ms | 50 ms | 2 |
| 72 | |
| 73 | For example if ondemand governor is configured to have a 50ms |
| 74 | sampling rate you get: |
| 75 | |
| 76 | In round 1, ondemand should have rather static 50% load and probably |
| 77 | won't ever switch up (as long as up_threshold is above). |
| 78 | |
| 79 | In round 2, if the ondemand sampling times exactly match the load/sleep |
| 80 | trigger of the cpufreq-bench, you will see no performance loss (compare with |
| 81 | below possible ondemand sample kick ins (1)): |
| 82 | |
| 83 | But if ondemand always kicks in in the middle of the load sleep cycles, it |
| 84 | will always see 50% loads and you get worst performance impact never |
| 85 | switching up (compare with below possible ondemand sample kick ins (2)):: |
| 86 | |
| 87 | 50 50 50 50ms ->time |
| 88 | load -----| |-----| |-----| |-----| |
| 89 | | | | | | | | |
| 90 | sleep |-----| |-----| |-----| |---- |
| 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 | |
| 96 | You can easily test all kind of load/sleep times and check whether your |
| 97 | governor in average behaves as expected. |
| 98 | |
| 99 | |
| 100 | ToDo |
| 101 | ==== |
| 102 | |
| 103 | Provide a gnuplot utility script for easy generation of plots to present |
| 104 | the outcome nicely. |
| 105 | |
| 106 | |
| 107 | cpufreq-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 avarage 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 | |
| 122 | Due to the high priority, the application may not be responsible for some time. |
| 123 | After the benchmark, the logfile is saved in OUTPUTDIR/benchmark_TIMESTAMP.log |
| 124 | |