freqbench is a comprehensive CPU benchmark that benchmarks each CPU frequency step on each frequency scaling domain (e.g. ARM DynamIQ/big.LITTLE cluster). It is based on a minimal Alpine Linux userspace with the EEMBC CoreMark workload and a Python benchmark coordinator.
Results include:
- Performance (CoreMark scores)
- Performance efficiency (CoreMarks per MHz)
- Power usage (in milliwatts)
- Energy usage (in millijoules and joules)
- Energy efficiency (ULPMark-CM scores: iterations per second per millijoule of energy used)
- Baseline power usage
- Time elapsed
- CPU frequency scaling stats during the benchmark (for validation)
- Diagnostic data (logs, kernel version, kernel command line, interrupts, processes)
- Raw power samples in machine-readable JSON format (for postprocessing)
A benchmark like this can be useful for many reasons:
- Creating energy models for EAS (Energy-Aware Scheduling)
- Correcting inaccurate EAS energy models
- Analyzing performance and power trends
- Comparing efficiency across SoC and CPU generations
- Improving performance and battery life of mobile devices by utilizing the race-to-idle phenomenon with efficient frequencies
Set the following kernel config options:
CONFIG_NO_HZ_FULL=y
CONFIG_CPU_FREQ_TIMES=n # may not exist
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_DEVTMPFS=y
CONFIG_HZ_100=yExample commit: kirin_defconfig: Configure for freqbench
If you have any commits that prevent userspace from controlling CPU affinities and utilization, frequencies, or anything of the sort, revert them for the benchmark to work properly. Here are some common examples of such commits in downstream kernels and their corresponding reverts:
- Performance-critical IRQs and kthreads
- Existing efficient frequency tables
- Preventing userspace from setting minimum CPU frequencies
- Ratelimiting fuel gauge queries
Example freqbench kernel adaptations:
- Pixel 2, msm-4.4
- ZenFone 6, msm-4.14
- Pixel 5, msm-4.19 (this device uses boot image v3, so it follows the manual boot image guide below)
Compile and flash your new kernel. Note that Android will not work properly on this kernel, so make sure you take a backup of your old boot image to restore later.
If necessary, adjust the config parameters in config.sh. Most modern devices will not need any changes. Run pack-zip.sh and flash freqbench-installer.zip.
Unplug the device immediately, before the device starts booting. Do not try to wait for it to finish booting. Leaving the device plugged in will invalidate all power results.
Finally, wait until the device reboots itself. Do not touch the device, any of its buttons, or plug/unplug it during the test. It will be frozen on the bootloader splash screen; do not assume that it is broken. The benchmark is expected to take a long time; 1 hour is reasonable for a slower CPU.
Once the benchmark is done, retrieve the results from /cache/freqbench if your device has a cache partition, or /persist/freqbench otherwise (newer devices with A/B partitions don't have a cache partition).
If you have any problems, check the troubleshooting section before opening an issue!
Manually creating a new boot image with the kernel and ramdisk is only for advanced users. Use the AnyKernel3 installer unless you have good reason to do this.
Additional kernel config options:
CONFIG_CMDLINE="isolcpus=1-7 nohz_full=1-7 loglevel=0 printk.devkmsg=on"
CONFIG_CMDLINE_EXTEND=yIf you do not have 8 CPU cores, adjust 1-7 to 1-<core count - 1>. Single-core CPUs are not supported.
Create a boot image with your modified kernel and the freqbench ramdisk:
For boot image v0/v1 devices:
cd boot-v1
./unpack.sh path/to/normal/boot.img
./pack.sh
# New boot image will be created as new.imgFor boot image v3 devices:
# Extract values from boot.img and update pack-img.sh accordingly
./pack-img.sh
# New boot image will be created as bench.imgAfter that, boot the modified image with fastboot boot if your device supports it, or flash it to the boot/recovery partition and boot that manually.
After the benchmark finishes, results can be found in /cache/freqbench, /persist/freqbench, or /mnt/vendor/persist/freqbench, in that order of preference. The first path that exists on your device will be used. Human-readable results, raw machine-readable JSON data, and diagnostic information are included for analysis.
Several post-processing scripts, all written in Python and some using matplotlib, are available:
Create a legacy EAS energy model for use with older kernels.
Optional argument after path to results: key_type/value_type
Key types:
- Frequency (default) - looks like
652800or2323200 - Capacity - looks like
139or1024
You must use the correct key type for your kernel. When in doubt, refer to your original energy model and check which one the numbers look more like.
In general, downstream Qualcomm kernels will use the following key types depending on version:
- 3.18: capacity
- 4.4: capacity
- 4.9: frequency
- 4.14: frequency
- 4.19: N/A (uses simplified energy model instead)
Modifying your kernel to switch from one to the other is left as an exercise for the reader.
Value types:
- Power (default)
- Energy (experimental, not recommended)
Do not change the value type unless you know what you're doing. The energy type only exists for testing purposes; do not expect it to work properly.
Once you have a full energy model generated, pick out the parts you need and incorporate them into your SoC device tree. In general, kernels 4.19 need capacity-dmips-mhz, while older kernels need efficiency when it comes to the contents of the CPU sections.
If you have an existing energy model that you want to use for idle and cluster costs, add it as an argument.
Example usage: ./legacy_em.py results.json cap/power old_model.dtsi
Create a simplified EAS energy model for use with newer kernels.
Because voltages defined by the CPU frequency scaling driver cannot easily be accessed from userspace, you will need to provide them. Each frequency step for each cluster have its voltage specified as an argument: cpu#.khz=microvolts
For Qualcomm SoCs on the msm-4.19 kernel, voltages can be obtained by booting the kernel (with or without freqbench doesn't matter, as long as you can get kernel logs) with this commit and searching for lines containing volt= in the kernel log.
For msm-4.9 and msm-4.14, the process is the same but with this commit and searching for open_loop_voltage instead.
Example usage: ./simplified_em.py results.json 1.300000=580000 1.576000=580000 1.614400=580000 1.864000=644000 1.1075200=708000 1.1363200=788000 1.1516800=860000 1.1651200=888000 1.1804800=968000 6.652800=624000 6.940800=672000 6.1152000=704000 6.1478400=752000 6.1728000=820000 6.1900800=864000 6.2092800=916000 6.2208000=948000 7.806400=564000 7.1094400=624000 7.1401600=696000 7.1766400=776000 7.1996800=836000 7.2188800=888000 7.2304000=916000 7.2400000=940000
Derive a list of efficient frequencies for each cluster and create a new results.json with only those frequencies included.
Note that this script is experimental and may not produce optimal results. Manual tuning of the resulting frequency tables is recommended.
Example usage: ./efficient_freqs.py results.json eff_results.json
Create a new results.json with only the specified frequencies included.
Example usage: ./filter_freqs.py results.json filtered_results.json 1.1516800 1.1804800 6.1478400 6.1728000 6.2208000 7.1766400 7.2188800 7.2304000 7.2400000
Graph a value for each cluster across different SoCs/CPUs.
Arguments:
- Add a SoC:
SoC-1:soc1/results.json - Specify the value to graph:
load/value(load is idle/active) - Set a flag:
+flagname(soccolor, minscl)
Example usage: ./cross_cpu_cluster_graph.py 835:results/p2/main/results.json 855:results/zf6/main/results.json 855+:results/rog2/main/results.json 765G:results/p5/new-final/results.json active/power_mean +soccolor +minscl
Graph a value for each cluster within the same SoC/CPU.
Example usage: ./unified_cluster_graph.py results.json coremark_score
Extract a value for each cluster within the same SoC/CPU and write the results into a CSV file.
Example usage: ./unified_cluster_csv.py results.json coremark_score cm_scores.csv
If your kernel panics on boot, disable CONFIG_CPU_FREQ_STAT. If that causes the kernel to fail to compile, cherry-pick cpufreq: Fix build with stats disabled.
Check kernel.log, pre- and post-bench interrupts, running processes, and cpufreq stats from the results directory to diagnose the issue.
If you have a slow CPU with a lot of frequency steps, this is not entirely unreasonable.
freqbench offers interactive debugging via SSH over virtual USB Ethernet; the device acts as a USB Ethernet adapter and exposes an SSH server on the internal network. Uncomment source /usb.sh in init.sh to enable it and boot freqbench again. The feature is disabled by default to avoid unnecessary USB setup that may influence benchmark results, so keeping it enabled for a final benchmark run is not recommended.
Connect your device to a computer over USB. You should see something like this in your kernel logs if you are running Linux:
[7064379.627645] usb 7-3: new high-speed USB device number 114 using xhci_hcd
[7064379.772208] usb 7-3: New USB device found, idVendor=0b05, idProduct=4daf, bcdDevice= 4.14
[7064379.772210] usb 7-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[7064379.772211] usb 7-3: Product: Alpine GNU/Linux
[7064379.772211] usb 7-3: Manufacturer: Linux
[7064379.772212] usb 7-3: SerialNumber: ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@10.15.19.82
[7064379.818904] rndis_host 7-3:1.0 usb0: register 'rndis_host' at usb-0000:47:00.1-3, RNDIS device, da:34:ab:99:c5:81
[7064379.870018] rndis_host 7-3:1.0 enp71s0f1u3: renamed from usb0
Run the SSH command in the serial number field to open a shell to the device. The password is empty, so just press enter when asked to input a password.