~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

TOMOYO Linux Cross Reference
Linux/tools/power/cpupower/bench/README-BENCH

Version: ~ [ linux-6.12-rc7 ] ~ [ linux-6.11.7 ] ~ [ linux-6.10.14 ] ~ [ linux-6.9.12 ] ~ [ linux-6.8.12 ] ~ [ linux-6.7.12 ] ~ [ linux-6.6.60 ] ~ [ linux-6.5.13 ] ~ [ linux-6.4.16 ] ~ [ linux-6.3.13 ] ~ [ linux-6.2.16 ] ~ [ linux-6.1.116 ] ~ [ linux-6.0.19 ] ~ [ linux-5.19.17 ] ~ [ linux-5.18.19 ] ~ [ linux-5.17.15 ] ~ [ linux-5.16.20 ] ~ [ linux-5.15.171 ] ~ [ linux-5.14.21 ] ~ [ linux-5.13.19 ] ~ [ linux-5.12.19 ] ~ [ linux-5.11.22 ] ~ [ linux-5.10.229 ] ~ [ linux-5.9.16 ] ~ [ linux-5.8.18 ] ~ [ linux-5.7.19 ] ~ [ linux-5.6.19 ] ~ [ linux-5.5.19 ] ~ [ linux-5.4.285 ] ~ [ linux-5.3.18 ] ~ [ linux-5.2.21 ] ~ [ linux-5.1.21 ] ~ [ linux-5.0.21 ] ~ [ linux-4.20.17 ] ~ [ linux-4.19.323 ] ~ [ linux-4.18.20 ] ~ [ linux-4.17.19 ] ~ [ linux-4.16.18 ] ~ [ linux-4.15.18 ] ~ [ linux-4.14.336 ] ~ [ linux-4.13.16 ] ~ [ linux-4.12.14 ] ~ [ linux-4.11.12 ] ~ [ linux-4.10.17 ] ~ [ linux-4.9.337 ] ~ [ linux-4.4.302 ] ~ [ linux-3.10.108 ] ~ [ linux-2.6.32.71 ] ~ [ linux-2.6.0 ] ~ [ linux-2.4.37.11 ] ~ [ unix-v6-master ] ~ [ ccs-tools-1.8.9 ] ~ [ policy-sample ] ~
Architecture: ~ [ i386 ] ~ [ alpha ] ~ [ m68k ] ~ [ mips ] ~ [ ppc ] ~ [ sparc ] ~ [ sparc64 ] ~

Diff markup

Differences between /tools/power/cpupower/bench/README-BENCH (Architecture mips) and /tools/power/cpupower/bench/README-BENCH (Architecture sparc64)


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

~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

kernel.org | git.kernel.org | LWN.net | Project Home | SVN repository | Mail admin

Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.

sflogo.php