-
Notifications
You must be signed in to change notification settings - Fork 229
likwid setFrequencies
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.
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 or your used boot loader.
-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 (performance, powersave)
-f/--freq freq Set current, minimal and maximal CPU frequency
-p Print current frequencies (CPUs + Uncore)
-l List available CPU frequencies
-m List available CPU governors
-F/--Freq freq Set current CPU frequency
-x/--min freq Set minimal CPU frequency
-y/--max freq Set maximal CPU frequency
--umin freq Set minimal Uncore frequency
--umax freq Set maximal Uncore frequency
-reset Set governor 'performance', set minimal and maximal frequency to
the CPU limits and deactivate turbo
-ureset Set Uncore frequencies to its min and max limits
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
[...]
Starting with version 4.3.0 the -p
switch prints also the min/max Uncore frequency.
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.
Some Intel CPUs provide the possibility to change the Uncore frequency. You can use the --umin
and --umax
command line options to set it. One problem with the Uncore frequency is that the minimal and maximal frequency limits are not readable in all system configurations. Therefore LIKWID defines a range of supported frequencies. To be sure that the frequency you adjusted as requested, measure the UNCORE_CLOCK
event using likwid-perfctr
.
Starting with LIKWID 4.3.2, it is possible to reset the CPU and Uncore frequencies to its full range to return to a defined state. There are different switches for CPU frequencies (-reset
) and Uncore frequencies (-ureset
):
-
-reset
: Change CPU frequencies to its minimal and maximal frequencies. If not specified, the turbo is deactivated and the maximum non-turbo frequency selected. The turbo reset setting can be set with-t <0|1>
. For the government, LIKWID checks first for a governorperformance
, afterwardsconservative
and finally falls back to the last on the list of available governors (-m
). -
-ureset
: Change the Uncore frequencies to minimum (lowest available CPU frequency, first atlikwid-setFrequencies -l
) and to maximum (highest turbo frequency if only a single core is running,C0
atlikwid-powermeter -i
)
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:
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
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
-
Applications
-
Config files
-
Daemons
-
Architectures
- Available counter options
- AMD
- Intel
- Intel Atom
- Intel Pentium M
- Intel Core2
- Intel Nehalem
- Intel NehalemEX
- Intel Westmere
- Intel WestmereEX
- Intel Xeon Phi (KNC)
- Intel Silvermont & Airmont
- Intel Goldmont
- Intel SandyBridge
- Intel SandyBridge EP/EN
- Intel IvyBridge
- Intel IvyBridge EP/EN/EX
- Intel Haswell
- Intel Haswell EP/EN/EX
- Intel Broadwell
- Intel Broadwell D
- Intel Broadwell EP
- Intel Skylake
- Intel Coffeelake
- Intel Kabylake
- Intel Xeon Phi (KNL)
- Intel Skylake X
- Intel Cascadelake SP/AP
- Intel Tigerlake
- Intel Icelake
- Intel Icelake X
- Intel SappireRapids
- ARM
- POWER
-
Tutorials
-
Miscellaneous
-
Contributing