| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124 |
- This is cpufreq-bench, a microbenchmark for the cpufreq framework.
- Purpose
- =======
- What is this benchmark for:
- - Identify worst case performance loss when doing dynamic frequency
- scaling using Linux kernel governors
- - Identify average reaction time of a governor to CPU load changes
- - (Stress) Testing whether a cpufreq low level driver or governor works
- as expected
- - Identify cpufreq related performance regressions between kernels
- - Possibly Real time priority testing? -> what happens if there are
- processes with a higher prio than the governor's kernel thread
- - ...
- What this benchmark does *not* cover:
- - Power saving related regressions (In fact as better the performance
- throughput is, the worse the power savings will be, but the first should
- mostly count more...)
- - Real world (workloads)
- Description
- ===========
- cpufreq-bench helps to test the condition of a given cpufreq governor.
- For that purpose, it compares the performance governor to a configured
- powersave module.
- How it works
- ============
- You can specify load (100% CPU load) and sleep (0% CPU load) times in us which
- will be run X time in a row (cycles):
- sleep=25000
- load=25000
- cycles=20
- This part of the configuration file will create 25ms load/sleep turns,
- repeated 20 times.
- Adding this:
- sleep_step=25000
- load_step=25000
- rounds=5
- Will increase load and sleep time by 25ms 5 times.
- Together you get following test:
- 25ms load/sleep time repeated 20 times (cycles).
- 50ms load/sleep time repeated 20 times (cycles).
- ..
- 100ms load/sleep time repeated 20 times (cycles).
- First it is calibrated how long a specific CPU intensive calculation
- takes on this machine and needs to be run in a loop using the performance
- governor.
- Then the above test runs are processed using the performance governor
- and the governor to test. The time the calculation really needed
- with the dynamic freq scaling governor is compared with the time needed
- on full performance and you get the overall performance loss.
- Example of expected results with ondemand governor:
- This shows expected results of the first two test run rounds from
- above config, you there have:
- 100% CPU load (load) | 0 % CPU load (sleep) | round
- 25 ms | 25 ms | 1
- 50 ms | 50 ms | 2
- For example if ondemand governor is configured to have a 50ms
- sampling rate you get:
- In round 1, ondemand should have rather static 50% load and probably
- won't ever switch up (as long as up_threshold is above).
- In round 2, if the ondemand sampling times exactly match the load/sleep
- trigger of the cpufreq-bench, you will see no performance loss (compare with
- below possible ondemand sample kick ins (1)):
- But if ondemand always kicks in in the middle of the load sleep cycles, it
- will always see 50% loads and you get worst performance impact never
- switching up (compare with below possible ondemand sample kick ins (2))::
- 50 50 50 50ms ->time
- load -----| |-----| |-----| |-----|
- | | | | | | |
- sleep |-----| |-----| |-----| |----
- |-----|-----|-----|-----|-----|-----|-----|---- ondemand sampling (1)
- 100 0 100 0 100 0 100 load seen by ondemand(%)
- |-----|-----|-----|-----|-----|-----|-----|-- ondemand sampling (2)
- 50 50 50 50 50 50 50 load seen by ondemand(%)
- You can easily test all kind of load/sleep times and check whether your
- governor in average behaves as expected.
- ToDo
- ====
- Provide a gnuplot utility script for easy generation of plots to present
- the outcome nicely.
- cpufreq-bench Command Usage
- ===========================
- -l, --load=<long int> initial load time in us
- -s, --sleep=<long int> initial sleep time in us
- -x, --load-step=<long int> time to be added to load time, in us
- -y, --sleep-step=<long int> time to be added to sleep time, in us
- -c, --cpu=<unsigned int> CPU Number to use, starting at 0
- -p, --prio=<priority> scheduler priority, HIGH, LOW or DEFAULT
- -g, --governor=<governor> cpufreq governor to test
- -n, --cycles=<int> load/sleep cycles to get an avarage value to compare
- -r, --rounds<int> load/sleep rounds
- -f, --file=<configfile> config file to use
- -o, --output=<dir> output dir, must exist
- -v, --verbose verbose output on/off
- Due to the high priority, the application may not be responsible for some time.
- After the benchmark, the logfile is saved in OUTPUTDIR/benchmark_TIMESTAMP.log
|
