likwid setFrequencies

likwid-setFrequencies: A tool to manipulate the frequency of CPU cores

Introduction

Often systems are configured to use as little power as needed and therefore reduce the clock frequency of single cores. For benchmarking purpose, it is important to have a defined environment where all CPU cores work at the same speed. The operation is commonly only allowed to privileged users since it may interfere with the needs of other users.

Starting with LIKWID version 3.1.2 we included a daemon and control script to change the frequency and scaling governor of affinity regions. All operations that require only readable access to the control files in sysfs are implemented in the script. Only the writeable access is forbidden for normal users and requires a more privileged daemon.

Notice

likwid-setFrequencies can only be used in conjunction with the acpi-cpufreq kernel module. The intel_pstate kernel module, introduced with Linux kernel 3.10, does not allow to fix the clock frequency of cores. In order to deactivate the intel_pstate module, add intel_pstate=disable to the kernel command line in GRUB.

Options

-h	 Help message
-v	 Version information
-c dom	 Likwid thread domain which to apply settings (default are all CPUs)
	 See likwid-pin -h for details
-g gov	 Set governor (conservative, ondemand, powersave, performance, turbo) (set to ondemand if omitted)
-f freq	 Set fixed frequency, implicitly sets userspace governor
-p	 Print current frequencies
-l	 List available frequencies
-m	 List available governors

Usage

At first, you need to know the available frequencies for your CPU cores:

$ likwid-setFrequencies -l
Available frequencies:
3.001, 3.0, 2.9, 2.7, 2.6, 2.5, 2.4, 2.2, 2.1, 2.0, 1.8, 1.7, 1.6, 1.5, 1.3, 1.2

In order to see which CPU core has which frequency:

$ likwid-setFrequencies -p
Current frequencies:
CPU 0: governor  performance frequency 3.001 GHz
CPU 1: governor  performance frequency 3.001 GHz
CPU 2: governor  performance frequency 3.001 GHz
CPU 3: governor  performance frequency 3.001 GHz
CPU 4: governor  performance frequency 3.001 GHz
CPU 5: governor  performance frequency 3.001 GHz
CPU 6: governor  performance frequency 3.001 GHz
CPU 7: governor  performance frequency 3.001 GHz
CPU 8: governor  performance frequency 3.001 GHz
CPU 9: governor  performance frequency 3.001 GHz
[...]

When you know a valid frequency for a range of CPU cores you can set them:

$ likwid-setFrequencies -c S0 -f 2.9

This sets all CPU cores of socket 0 to a frequency of 2.9 GHz. If the scaling governor of core 0 was something other than userspace, it is automatically set to userspace. If the -c is omitted, the whole node (affinity domain N) is assumed, thus all cores are set to the frequency. If you want to change the frequency of specific CPUs, you can set a comma-separated list or a range of IDs like 0,1,4-7.

You can also change only the governor of an affinity domain or single CPUs. The available governors can be retrieved with:

$ likwid-setFrequencies -m
Available governors:
conservative, ondemand, powersave, performance, turbo

The common governors are performance (setting the core to the maximal frequency and eventually enable Turbo mode where SMT threads are deactivated) and ondemand (scales the frequency of the CPU core regarding the current workload of the CPU, commonly used to save energy). The other two governors conservative and powersave are allowed but not recommended for throughput systems.

$ likwid-setFrequencies -c C0 -g performance

Sets the scaling governor of all CPU cores in the cache group 0 to the performance governor. In order to get all affinity domains that are supported by the system, you can use the likwid-pin tool:

$ likwid-pin -p

Prints all available affinity domains, see likwid-pin Wiki page.

Configuration of the setFreq daemon

Since the daemon process likwid-setFreq requires higher privileges than the control script likwid-setFrequency. There are two methods to grant this to the daemon:

setuid root

The common way is to set suid permission bit for the daemon process. The daemon process is executed not with the UID of the caller anymore, but the UID is changed to the root UID before execution. There exist some default GNU tools that are configured like this like su or (un)mount. You have to change to user/owner of the daemon process and set the suid bit:

$ sudo chown root:root likwid-setFreq
$ sudo chmod u+s likwid-setFreq

capabilities

Since the Linux kernel 2.6.24 most file systems support the storing of capability flags besides executables. There exist a bunch of flags that give administrators a fine grained management option for risky executables. There are advantages and also disadvantages when using capabilities. The main advantages are that the process is still executed with the UID of the caller and only the rights that are needed by the processes can be granted. As a disadvantage, the Linux kernel needs to be compiled with special configuration options to enable the storing of capability flags in the file system. Additionally not all file system seem to support that feature. In order to make the daemon work with capability flags:

$ sudo chmod 0666 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
$ sudo chmod 0666 /sys/devices/system/cpu/cpu*/cpufreq/scaling_setspeed
$ sudo setcap cap_sys_rawio+ep likwid-setFreq

This enables the daemon until the next reboot. In order to make the permissions persistent, you can use the udev system:

# cat > /etc/udev/rules.d/99-persistent-setFreq.rules <<EOF
> KERNEL=="cpu*", RUN+="/bin/chmod 0666 /sys/devices/system/cpu/cpu%n/cpufreq/scaling_governor"
> KERNEL=="cpu*", RUN+="/bin/chmod 0666 /sys/devices/system/cpu/cpu%n/cpufreq/scaling_setspeed"
> EOF