Measure and compare performance per watt on an Arm Linux system
Introduction
Prepare the Arm Linux system
Discover CPU frequency and power controls
Collect synchronized power and thermal telemetry
Establish an OpenSSL performance and power baseline
Compare Linux CPU frequency governors
Compare CPU maximum-frequency limits
Calculate performance and energy efficiency
Next Steps
Measure and compare performance per watt on an Arm Linux system
Introduction
Prepare the Arm Linux system
Discover CPU frequency and power controls
Collect synchronized power and thermal telemetry
Establish an OpenSSL performance and power baseline
Compare Linux CPU frequency governors
Compare CPU maximum-frequency limits
Calculate performance and energy efficiency
Next Steps
Who is this for?
This is an advanced topic for software developers and performance engineers who want to measure and compare energy efficiency across CPU frequency configurations on Arm Linux systems.
What will you learn?
Upon completion of this Learning Path, you will be able to:
- Discover CPU frequency controls and power, temperature, and fan sensors on an Arm Linux system
- Collect synchronized CPU frequency, power, temperature, and fan telemetry during a workload
- Compare Linux CPUFreq governors and maximum-frequency limits using a repeatable OpenSSL workload
- Calculate throughput per watt and energy consumed per unit of work
Prerequisites
Before starting, you will need the following:
- An Arm Linux system with root or sudo access and Python 3 installed
- CPU frequency policies available under
/sys/devices/system/cpu/cpufreq/ - CPU and I/O power sensors exposed through Linux hwmon
Summary
This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
hwmon telemetry, and an OpenSSL SHA-256 workload. You’ll inspect frequency policies and sensors, create a synchronized telemetry logger, and establish a baseline. Then, you’ll compare governors and frequency caps, and calculate throughput per watt and energy per gigabyte.Frequently asked questions
These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
hwmon driver. On the example Thelio Astra, apm_xgene provides those channels. On another system, identify the equivalent labeled inputs before you run the logger. Treat the sum as an SoC estimate that excludes memory, storage, fans, and power-supply losses./sys/devices/system/cpu/cpufreq/ and compare their count with nproc. If the counts differ, your system might group multiple CPUs into one policy. Use this layout to understand which CPUs change together before you run experiments.apm_xgene and system76_thelio_io with the device names reported by /sys/class/hwmon/hwmon*/name, then update sensor labels if your drivers use different labels. The logger accepts an output filename and sampling interval as its first and second arguments.sudo ./run-openssl.sh LABEL SECONDS. The script uses openssl speed with SHA-256, a fixed 16384-byte buffer, and -multi "$(nproc)" to start one worker per online CPU. Check the saved openssl-output.txt file for the aggregate throughput.scaling_available_governors file. The set-governor.sh script validates this and exits if any policy lacks the governor. Check that scaling_min_freq and scaling_max_freq remain unchanged across runs.