Hi, I ran into something strange while trying to set the CPU governor on a server and wanted to see if this is expected behaviour or not. While doing high speed network testing,one of the things I'm tuning is to set the CPU governor to Performance, using cpufreq-set from cpufrequtils: cpufreq-set -r -g performance $CPU_NUM On a system that has a Xeon Gold CPU, this works just fine, the governor can be set and using cpufreq-info tells me all manner of info about the CPU. On a different system that has a Xeon Platinum CPU, this does not happen. On that machine, attempts to set the CPU frequency governor results in a segfault of cpufreq-set # for x in `seq 0 48`; do cpufreq-set -r -g performance $x; done Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) ... The above worked just fine setting the Performance governor on all 72 cores on the system with the Xeon Gold CPUs, but for the 48 cores on the Platinum system, there was a segfault for each attempt. And using cpufreq-info results in this: # cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@xxxxxxxxxxxxxxx, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 2: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. ... Both systems were running Ubuntu 16.04.4 using the latest 4.13 HWE kernel. (4.13.0-38.43~16.04.1) The CPUs ID as follows: Intel(R) Xeon(R) Platinum 8160T CPU @ 2.10GHz Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz One additional thing I noticed is that since Linux treats each core as a CPU, -r doesn't do anything. The man page says: -r --related modify all hardware-related CPUs at the same time Which sounds like "set the governor for every core on physical CPU X" however, in practice, I had to set every core individually (hence the loop above). Also, contrary to the man page for cpufreq-set, I didn't have to specify -c for each core, just the core number itself was sufficient: cpufreq-set -g performance 14 would set the governor for core/CPU 14, I didn't need to specify -c 14 or --cpu 14. Unfortunately, I did not have the chance to run the 4.15 kernel from Ubuntu 18.04 on this system, and I've since lost access to this hardware (it was hosted remotely in a partner lab). But before I raised this as a bug against Ubuntu, I wanted to understand more about the segfaults and if maybe this is a bug in cpufreq-set first. Thanks, Jeff -- Jeff Lane TPP / Server Certification Lead "Entropy isn't what it used to be." -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
