Related articles Show
CPU performance scaling enables the operating system to scale the CPU frequency up or down in order to save power or improve performance. Scaling can be done automatically in response to system load, adjust itself in response to ACPI events, or be manually changed by user space programs. The Linux kernel offers CPU performance scaling via the CPUFreq subsystem, which defines two layers of abstraction:
A default scaling driver and governor are selected automatically, but userspace tools like cpupower, acpid, Laptop Mode Tools, or GUI tools provided for your desktop environment, may still be used for advanced configuration. thermaldthermald is a Linux daemon used to prevent the overheating of Intel CPUs. This daemon proactively controls thermal parameters using P-states, T-states, and the Intel power clamp driver. thermald can also be used for older Intel CPUs. If the latest drivers are not available, then the daemon will revert to x86 model specific registers and the Linux "cpufreq subsystem" to control system cooling. By default, it monitors CPU temperature using available CPU digital temperature sensors and maintains CPU temperature under control, before hardware takes aggressive correction action. If there is a skin temperature sensor in thermal sysfs, then it tries to keep skin temperature under 45C. The associated systemd unit is thermald.service, which should be started and enabled. i7zi7z is an i7 (and now i3, i5, i7, i9) CPU reporting tool for Linux. It can be launched from a Terminal with the command i7z or as GUI with i7z-gui. turbostatturbostat can display the frequency, power consumption, idle status and other statistics of the modern Intel and AMD CPUs. cpupowercpupower is a set of userspace utilities designed to assist with CPU frequency scaling. The package is not required to use scaling, but is highly recommended because it provides useful command-line utilities and a systemd service to change the governor at boot. The configuration file for cpupower is located in /etc/default/cpupower. This configuration file is read by a bash script in /usr/lib/systemd/scripts/cpupower which is activated by systemd with cpupower.service. You may want to enable cpupower.service to start at boot. cpupower-guicpupower-guiAUR is a graphical utility designed to assist with CPU frequency scaling. The GUI is based on GTK and is meant to provide the same options as cpupower. cpupower-gui can change the maximum/minimum CPU frequency and governor for each core. The application handles privilege granting through polkit and allows any logged-in user in the wheel user group to change the frequency and governor. power-profiles-daemonThe powerprofilesctl command-line tool from power-profiles-daemon handles power profiles (e.g. balanced, power-saver, performance) through the power-profiles-daemon service. GNOME and KDE also provide graphical interfaces for profile switching; see the following:
See the project's README for more information on usage, use cases, and comparisons with similar projects. Start/enable the power-profiles-daemon service. Note that when powerprofilesctl is launched, it also attempts to start the service (see the unit status of dbus.service). Note: power-profiles-daemon conflicts with other power management services such as TLP, tunedAUR and system76-powerAUR. To use one of the aforementioned services instead without uninstalling power-profiles-daemon (due to its potential status as a dependency), disable the power-profiles-daemon service by masking it (see also [1], [2]). Scaling driversScaling drivers implement the CPU-specific details of setting frequencies specified by the governor. Strictly speaking, the ACPI standard requires power-performance states (P-states) that start at P0, and becoming decreasingly performant. This functionality is called SpeedStep on Intel, and PowerNow! on AMD. In practice, though, processors provide methods for specifying specific frequencies rather than being restricted to fixed P-states, which the scaling drivers handle. Note:
cpupower requires modules to know the limits of the native CPU:
To see a full list of available modules, run: $ ls /usr/lib/modules/$(uname -r)/kernel/drivers/cpufreq/Load the appropriate module (see Kernel modules for details). Once the appropriate cpufreq driver is loaded, detailed information about the CPU(s) can be displayed by running $ cpupower frequency-infoSetting maximum and minimum frequenciesIn some cases, it may be necessary to manually set maximum and minimum frequencies. To set the maximum clock frequency (clock_freq is a clock frequency with units: GHz, MHz): # cpupower frequency-set -u clock_freqTo set the minimum clock frequency: # cpupower frequency-set -d clock_freqTo set the CPU to run at a specified frequency: # cpupower frequency-set -f clock_freqNote:
Alternatively, you can set the frequency manually: # echo value > /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freqThe available values can be found in /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies or similar. [3] Configuring frequency boostingSome processors support raising their frequency above the normal maximum for a short burst of time, under appropriate thermal conditions. On Intel processors, this is called Turbo Boost, and on AMD processors this is called Turbo-Core. Setting via sysfs (intel_pstate)intel_pstate has a driver-specific interface for prohibiting the processor from entering turbo P-States: Setting via sysfs (Other scaling drivers)For scaling drivers other than intel_pstate, if the driver supports boosting then the /sys/devices/system/cpu/cpufreq/boost attribute will be present, and can be used to disable/enable boosting: # echo 0 > /sys/devices/system/cpu/cpufreq/boostSetting via x86_energy_perf_policyOn Intel processors, x86_energy_perf_policy can also be used to configure Turbo Boost: # x86_energy_perf_policy --turbo-enable 0Scaling governorsScaling governors are power schemes determining the desired frequency for the CPU. Some request a constant frequency, others implement algorithms to dynamically adjust according to the system load. The governors included in the kernel are: The factual accuracy of this article or section is disputed.Reason: There is /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors which contains performance powersave when the intel_pstate driver is used. The note from [4] was probably more accurate. Also the "active mode" of intel_pstate is not described anywhere. (Discuss in Talk:CPU frequency scaling) Note: Each governor is compatible with any scaling driver. However, the intel_pstate scaling driver in active mode will bypass the governor, rendering this section inapplicable.
Depending on the scaling driver, one of these governors will be loaded by default:
Warning: Use CPU monitoring tools (for temperatures, voltage, etc.) when changing the default governor. To activate a particular governor, run: # cpupower frequency-set -g governorNote:
Alternatively, you can activate a governor on every available CPU manually: # echo governor | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governorwhere governor is the name of the governor, mentioned in the above table, that you want to activate. Tip: To monitor cpu speed in real time, run: $ watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq Tuning the ondemand governorSee the kernel documentation for details. Switching thresholdTo set the threshold for stepping up to another frequency: To set the threshold for stepping down to another frequency: # echo -n percent > /sys/devices/system/cpu/cpufreq/<governor>/down_thresholdSampling rateThe sampling rate determines how frequently the governor checks to tune the CPU. sampling_down_factor is a tunable that multiplies the sampling rate when the CPU is at its highest clock frequency thereby delaying load evaluation and improving performance. Allowed values for sampling_down_factor are 1 to 100000. This tunable has no effect on behavior at lower CPU frequencies/loads. To read the value (default = 1), run: $ cat /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factorTo set the value, run: # echo -n value > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factorMake changes permanentTo have the desired scaling enabled at boot, kernel module options and systemd-tmpfiles are regular methods. For example, changing the up_threshold to 10: /etc/tmpfiles.d/ondemand.conf w- /sys/devices/system/cpu/cpufreq/ondemand/up_threshold - - - - 10However, as noted in systemd-tmpfiles, in some cases race conditions may exist and one can use udev to avoid them. For example: $ udevadm info -a /sys/devices/cpu ... KERNEL=="cpu" SUBSYSTEM=="event_source" ... /etc/udev/rules.d/cpu.rules KERNEL=="cpu", SUBSYSTEM=="event_source", ACTION=="add", RUN+="/bin/sh -c 'echo performance | tee /sys/devices/system/cpu/cpufreq/policy*/scaling_governor'" $ udevadm test /sys/devices/cpu ... Reading rules file: /usr/lib/udev/rules.d/99-systemd.rules Reading rules file: /etc/udev/rules.d/cpu.rules ...To have the rule already applied in the initramfs, add the file to your mkinitcpio.conf, like in a different example in udev#Debug output. Tip:
Intel performance and energy bias hintThe Intel performance and energy bias hint (EPB) is an interface provided by Intel CPUs to allow for user space to specify the desired power-performance tradeoff, on a scale of 0 (highest performance) to 15 (highest energy savings). The EPB register is another layer of performance management functioning independently from frequency scaling. It influences how aggressive P-state and C-state selection will be, and informs internal model-specific decision making that affects energy consumption. Common values and their aliases, as recognized by sysfs and x86_energy_perf_policy are:
Setting via sysfsThe EPB can be set using a sysfs attribute: # echo epb > /sys/devices/system/cpu/cpu*/power/energy_perf_biasSetting via x86_energy_perf_policyWith x86_energy_perf_policy: # x86_energy_perf_policy epbSetting via cpupowerWith cpupower: # cpupower set -b epb_valueWarning: cpupower does not support the string aliases. If given a string, it will silently set the EPB to 0, corresponding to max performance. Other x86 Energy FlagsEnable Hardware P-States with x86_energy_perf_policy: Set "default" policy: The changes are temporary. See x86_energy_perf_policy(8) for more info. CPU idle driverThe intel_idle CPU idle driver is used automatically for modern Intel CPUs instead of the acpi_idle driver. This driver is currently automatically used for Sandy Bridge and newer CPUs. The intel_idle may ignore the BIOS C-State settings. If you encounter a problem while using this driver, add intel_idle.max_cstate=0 to your kernel line. Interaction with ACPI eventsUsers may configure scaling governors to switch automatically based on different ACPI events such as connecting the AC adapter or closing a laptop lid. A quick example is given below, however it may be worth reading full article on acpid. Events are defined in /etc/acpi/handler.sh. If the acpid package is installed, the file should already exist and be executable. For example, to change the scaling governor from performance to conservative when the AC adapter is disconnected and change it back if reconnected: /etc/acpi/handler.sh [...] ac_adapter) case "$2" in AC*) case "$4" in 00000000) echo "conservative" >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo -n $minspeed >$setspeed #/etc/laptop-mode/laptop-mode start ;; 00000001) echo "performance" >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo -n $maxspeed >$setspeed #/etc/laptop-mode/laptop-mode stop ;; esac ;; *) logger "ACPI action undefined: $2" ;; esac ;; [...]TroubleshootingThe factual accuracy of this article or section is disputed.Reason: Unverifiable and vague statements, lots of "some"s and "maybe"s. Troubleshooting items need to address concrete problems. (Discuss in Talk:CPU frequency scaling)
BIOS frequency limitationSome CPU/BIOS configurations may have difficulties to scale to the maximum frequency or scale to higher frequencies at all. This is most likely caused by BIOS events telling the OS to limit the frequency resulting in /sys/devices/system/cpu/cpu0/cpufreq/bios_limit set to a lower value. Either you just made a specific Setting in the BIOS Setup Utility, (Frequency, Thermal Management, etc.) you can blame a buggy/outdated BIOS or the BIOS might have a serious reason for throttling the CPU on its own. Reasons like that can be (assuming your machine's a notebook) that the battery is removed (or near death) so you are on AC-power only. In this case a weak AC-source might not supply enough electricity to fulfill extreme peak demands by the overall system and as there is no battery to assist this could lead to data loss, data corruption or in worst case even hardware damage! Not all BIOS'es limit the CPU-Frequency in this case, but for example most IBM/Lenovo Thinkpads do. Refer to thinkwiki for more thinkpad related info on this topic. If you checked there is not just an odd BIOS setting and you know what you are doing you can make the Kernel ignore these BIOS-limitations. Warning: Make sure you read and understood the section above. CPU frequency limitation is a safety feature of your BIOS and you should not need to work around it. A special parameter has to be passed to the processor module. For trying this temporarily change the value in /sys/module/processor/parameters/ignore_ppc from 0 to 1. For setting it permanently Kernel modules#Setting module options describes alternatives. For example, you can add processor.ignore_ppc=1 to your kernel boot line, or create /etc/modprobe.d/ignore_ppc.conf # If the frequency of your machine gets wrongly limited by BIOS, this should help options processor ignore_ppc=1See also |