Introduction: The Imperative of Low Latency in AR/VR

Augmented Reality (AR) and Virtual Reality (VR) applications demand an unparalleled level of responsiveness and sustained performance from their underlying hardware. Even slight delays in processing, often measured in milliseconds, can lead to motion sickness, disorientation, and a significant degradation of user experience. At the heart of achieving this low-latency nirvana on Android devices lies the efficient and precise management of the Central Processing Unit (CPU) frequency. The `cpufreq` subsystem in the Linux kernel, upon which Android is built, dictates how CPU core frequencies are scaled up and down based on workload. For AR/VR, the default `cpufreq` policies, optimized for general-purpose usage and power saving, often fall short. This article delves into the intricacies of customizing these policies to unlock sustained, high-performance computing essential for immersive AR/VR.

Understanding `cpufreq`: The Android CPU Frequency Scaling Subsystem

The `cpufreq` subsystem is a critical component of the Linux kernel responsible for dynamic voltage and frequency scaling (DVFS). Its primary goal is to optimize power consumption while maintaining acceptable performance levels. It achieves this through a combination of CPUFreq drivers, governors, and policies.

CPU Frequency Governors and Policies

A `cpufreq` governor is a kernel module that implements a specific algorithm to decide how and when to change CPU frequencies. Common governors include:

• performance: Forces the CPU to its highest possible frequency, regardless of load. Ideal for peak performance but consumes significant power.
• powersave: Forces the CPU to its lowest possible frequency, prioritizing power efficiency over performance.
• ondemand: Scales CPU frequency dynamically based on system load. Rapidly scales up when load is high, scales down when idle.
• interactive: Similar to `ondemand` but more aggressive in scaling up, often reacting faster to interactive workloads.
• schedutil: A newer, more intelligent governor that works in conjunction with the kernel’s scheduler (EAS) to make frequency scaling decisions based on CPU utilization and workload characteristics.

Each CPU or cluster of CPUs on an SoC typically has its own `cpufreq` policy, managed via the sysfs interface at paths like /sys/devices/system/cpu/cpuX/cpufreq/. Within these directories, parameters like scaling_governor, scaling_min_freq, and scaling_max_freq can be configured.

Android’s Interaction with `cpufreq`

Android applications, especially those demanding high performance, interact with the kernel’s power management through various mechanisms. Android’s power hints (e.g., PowerManager.ACQUIRE_PARTIAL_WAKE_LOCK with a CPU hint, or `PerformanceManager` APIs) and `cgroup` settings can influence CPU frequency. However, these are often overridden or limited by the underlying `cpufreq` governor’s settings and thermal constraints. For AR/VR, these hints might not be aggressive or sustained enough, leading to throttling.

Diagnosing Performance and Latency Issues

Before customizing `cpufreq`, it’s crucial to identify if CPU frequency is indeed the bottleneck. Signs include inconsistent frame rates, unexpected hitches or stutters, and overall sluggishness in intensive AR/VR scenes. Tools for diagnosis:

• perfetto / systrace: These powerful tracing tools provide detailed timelines of CPU utilization, thread states, GPU activity, and more. Look for CPU frequency drops coinciding with frame drops or increased frame times.
• adb shell dumpsys cpuinfo: Provides a snapshot of CPU usage across processes.
• adb shell top -m 10: Shows real-time CPU usage for the top processes.
• adb shell cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq: Continuously monitor current CPU frequencies.
• ftrace: For deep kernel-level analysis, tracing governor decisions.

Pay attention to thermal throttling indicators. If your device frequently hits high temperatures and then scales down CPU frequency dramatically, you’re facing a thermal limit, which often dictates `cpufreq` behavior.

Strategies for Customizing `cpufreq` for AR/VR

Customizing `cpufreq` for AR/VR involves both kernel-level configurations and userspace runtime adjustments.

Kernel-Level Configuration

The most robust way to set default `cpufreq` behavior is within the kernel’s device tree (DTS/DTB) or through kernel build options.

• Device Tree Overlays (DTS/DTB): The device tree describes the hardware platform to the kernel. For each CPU cluster, you can specify default governors, min/max frequencies, and other parameters. This is typically done by modifying the `cpu` nodes within your device’s `dts` files. For instance, you might set the `operating-points-v2` property to define frequency tables and optionally a default governor.

/ {  cpus {    #address-cells = <1>;    #size-cells = <0>;    cpu@0 {      compatible = "arm,cortex-a76";      reg = <0>;      operating-points-v2 = <&cpu_opp_table0>;      cpu-policy {        cpufreq-min-freq = <1500000>;        cpufreq-max-freq = <2800000>;        cpufreq-governor = "schedutil";      };    };    // ... other CPUs/clusters    cpu_opp_table0: opp_table0 {      compatible = "operating-points-v2";      opp-shared;      opp-supported-hw = <0x01 0x01 0x01>;      // Define your specific frequency and voltage points      opp@2800000000 {        opp-hz = <2800000000>;        opp-microvolt = <1000000>;        clock-latency-ns = <200000>;      };      opp@1500000000 {        opp-hz = <1500000000>;        opp-microvolt = <850000>;        clock-latency-ns = <200000>;      };    };  };}

Setting `cpufreq-governor = "performance"` in the DTS will make `performance` the default at boot. This requires recompiling the kernel and flashing the new boot image.

• Kernel Configuration (`menuconfig`): The kernel build system allows you to select a default governor via `CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` or similar options. While less flexible than DTS, it ensures a baseline.

Userspace Dynamic Tuning via SysFS

For runtime adjustments or finer-grained control, the sysfs interface is invaluable. These changes are typically temporary and reset on reboot unless persisted through `init.rc` scripts.

Common `sysfs` parameters:

• /sys/devices/system/cpu/cpuX/cpufreq/scaling_governor: Sets the governor for CPU X.
• /sys/devices/system/cpu/cpuX/cpufreq/scaling_min_freq: Sets the minimum frequency.
• /sys/devices/system/cpu/cpuX/cpufreq/scaling_max_freq: Sets the maximum frequency.
• Governor-specific tunables: Paths like /sys/devices/system/cpu/cpuX/cpufreq/ondemand/up_threshold allow fine-tuning of governor behavior (e.g., how quickly `ondemand` scales up).

You can use `adb shell` to modify these:

# Check available governorsfor cpu in /sys/devices/system/cpu/cpu*; do    echo "$(basename $cpu): $(cat $cpu/cpufreq/scaling_available_governors)"done# Set governor for all CPUs to 'performance' (replace with 'schedutil' for EAS systems)for cpu in /sys/devices/system/cpu/cpu*; do    echo performance > $cpu/cpufreq/scaling_governor    echo "$(basename $cpu) governor set to performance"done# Set min/max frequencies (example for CPU0, adjust based on actual frequencies)CPU0_MAX_FREQ=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies | awk '{print $NF}')echo $CPU0_MAX_FREQ > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freqecho $CPU0_MAX_FREQ > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freqecho "CPU0 forced to max freq: $CPU0_MAX_FREQ"# Example for aggressively tuning 'schedutil' (requires schedutil governor to be active)echo 90 > /sys/devices/system/cpu/cpu0/cpufreq/schedutil/hispeed_freq_thresholdecho 10000 > /sys/devices/system/cpu/cpu0/cpufreq/schedutil/rate_limit_us

These commands are temporary. To make them persistent across reboots, they must be executed early in the boot process, typically via an `init.rc` script or a custom service.

Custom Governor Considerations

While `performance` and aggressively tuned `schedutil` or `interactive` often suffice, for extremely specialized AR/VR systems, a custom `cpufreq` governor might be considered. This involves writing a kernel module to implement a tailored frequency scaling logic, which is a highly complex task and generally beyond the scope of most customisations.

AR/VR Specific `cpufreq` Tuning Example: Sustained Performance Profile

The goal for AR/VR is to maintain consistently high CPU frequencies to minimize processing latency, even under sustained load, without immediately succumbing to thermal throttling.

Step-by-Step Tuning

1. Identify CPU Clusters and Frequencies: Before making changes, understand your SoC’s CPU architecture. Android devices often have big.LITTLE configurations. You’ll want to apply settings to all relevant performance clusters. Use `adb shell cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies` to list all available frequencies for each CPU.
2. Set Governor to `performance` or Aggressively Tuned `schedutil`: For maximum performance, `performance` governor is the most straightforward. For systems leveraging Energy Aware Scheduling (EAS), `schedutil` can be tuned to be very aggressive by lowering its rate limits and raising thresholds, potentially offering a better balance with thermal management if tweaked correctly.
3. Adjust Minimum Frequencies: Set `scaling_min_freq` to a high baseline, or even to `scaling_max_freq` for specific performance-critical clusters. This ensures the CPU never drops below a certain frequency, even when perceived load is low.
4. Thermal Management (with extreme caution): Directly disabling thermal throttling is highly risky and can damage hardware. Instead, one might adjust thermal trip points (`/sys/class/thermal/thermal_zoneX/trip_point_Y_temp`) to allow for higher temperatures before throttling. This should only be done with adequate cooling solutions and continuous monitoring. A safer approach is to rely on `schedutil` with careful tuning, as it can be more aware of thermal limits via EAS.
5. Persistence via `init.rc`: Create a new `init.rc` file (e.g., `init.perf_tune.rc`) or modify an existing one in your device’s `ramdisk` or `vendor` partition.

# Example init.perf_tune.rc in /vendor/etc/init/ or /system/etc/init/on early-init    # Set performance governor for all CPUs    write /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor performance    write /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor performance    write /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor performance    write /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor performance    # Assuming a big.LITTLE setup, set min_freq for big cores to max    # Replace with actual max freq values for your device    write /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq 2800000    write /sys/devices/system/cpu/cpu5/cpufreq/scaling_min_freq 2800000    write /sys/devices/system/cpu/cpu6/cpufreq/scaling_min_freq 2800000    write /sys/devices/system/cpu/cpu7/cpufreq/scaling_min_freq 2800000    # You might also set scaling_max_freq to ensure it doesn't drop    write /sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq 2800000    # ... similar for other performance cores

Monitoring and Validation

After applying changes, rigorously test with your AR/VR applications. Continuously monitor `scaling_cur_freq` for all CPUs. Use `perfetto` to analyze frame times and check for any unexpected frequency drops. Monitor thermal sensors (`/sys/class/thermal/thermal_zone*/temp`) to ensure the device remains within safe operating temperatures. Compare performance metrics (e.g., average frame rate, 99th percentile latency) before and after tuning.

Conclusion: Balancing Performance, Thermal Management, and Power

Customizing Android’s `cpufreq` policies is a powerful technique to achieve the sustained, low-latency performance critical for cutting-edge AR/VR experiences. By understanding governors, sysfs controls, and kernel configurations, developers and system integrators can fine-tune their devices beyond default settings. However, this power comes with responsibility. Aggressive `cpufreq` settings significantly increase power consumption and thermal load. A careful balance must be struck, considering the specific AR/VR workload, device cooling capabilities, and battery life expectations. Thorough testing and validation are paramount to ensure stability and prevent hardware damage. The journey to true AR/VR immersion often starts with precisely engineered performance at the core.