Bdtyktl

I have an Intel i7-6900K, 8 cores/16 hyper threads.

I have conky running on my desktop and it shows each of the 8 hardware core clock rates. Prior to the upgrade to 18.04 (from 16.04), each core scaled individually and the "on demand" policy seemed to work well, with a core increased to turbo speed under load (for example a single thread working hard) and the other cores staying throttled. Under 18.04, the cores appear to ramp up and down in parallel.

The policies available in 18.04 are "Performance" and "On demand". With the "Performance" policy active, which is the default after the upgrade, all of the cores stay above the base frequency of 3.2Ghz at around 3.45-3.53Ghz. I can enable the "On demand" policy by enabling the service via systemctl and rebooting. But then all the cores stay in around the 2.5Ghz level or so, and even under sustained load, none of the cores scale all the way up.

Under 16.04, the cores stayed at a relatively low clock speed and then scaled up almost instantly under load individually.

The situation is rather confusing now, as much of the documentation online doesn't apply to newer processors and/or newer kernels. More confusing is that one could use ACPI to control CPU clock frequency.

Is there a guide anywhere that has all or some of the following information:

• Which processors should be covered by which scaling methods in Linux?


• What mechanisms are available (cpufreq, ACPI, neither, something else)


• How to accurately read current CPU speed. For example, one might thinkg that "cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq" would be accurate, but the documentation says it may not be accurate:

"In the majority of cases, this is the frequency of the last P-state requested by the scaling driver from the hardware using the scaling interface provided by it, which may or may not reflect the frequency the CPU is actually running at (due to hardware design and other limitations)"

Thanks for any help. I'll attempt to double check and document all the information that I collect and post it somewhere.

The main thing for your processor is that there is only one Phase Locked Loop (PLL - which scales the CPU clock up and down) in the processor package. Therefore it has always been the case that the CPUs scale up and down in unision. The reason it used to seem different was that the acpi-cpufreq CPU scaling driver used to report what it thought the CPU frequencies should be rather than what they actually were. Now it reports what the frequencies actually are.

For almost all users / scenarios using cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq provides a good enough indicator as to what the individual CPU frequencies are. The reason the document has that disclaimer line it that it is possible that the information can be a little stale if a CPU has been idle with its clock stopped for awhile.

By default your processor should be using the intel-pstate CPU frequency driver and it has HWP (Hardware pstate control), meaning the processor itself can decide the requested pstate (CPU frequency). Note that all pstate requests to go into the PLL stuff, along with idle states and a decision is made as to at what pstate the PLL will operate. You seem to be using the acpi-cpufreq CPU scaling driver, so I guess you have disabled the intel_pstate driver, which is fine, if that is your preference.

As for CPU frequency scaling tools / methods. I never use them. I only manage CPU frequency scaling with the basic primitive commands via the command line.

As to why your CPUs do not seem to go into the turbo range now, we would need more information to provide help. Starting with, for example:

doug@s15:~$ grep . /sys/devices/system/cpu/cpufreq/policy*/scaling_driver

/sys/devices/system/cpu/cpufreq/policy0/scaling_driver:intel_pstate

/sys/devices/system/cpu/cpufreq/policy1/scaling_driver:intel_pstate

/sys/devices/system/cpu/cpufreq/policy2/scaling_driver:intel_pstate

/sys/devices/system/cpu/cpufreq/policy3/scaling_driver:intel_pstate

/sys/devices/system/cpu/cpufreq/policy4/scaling_driver:intel_pstate

/sys/devices/system/cpu/cpufreq/policy5/scaling_driver:intel_pstate

/sys/devices/system/cpu/cpufreq/policy6/scaling_driver:intel_pstate

/sys/devices/system/cpu/cpufreq/policy7/scaling_driver:intel_pstate

doug@s15:~$ grep . /sys/devices/system/cpu/cpufreq/policy*/scaling_governor

/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:powersave

/sys/devices/system/cpu/cpufreq/policy1/scaling_governor:powersave

/sys/devices/system/cpu/cpufreq/policy2/scaling_governor:powersave

/sys/devices/system/cpu/cpufreq/policy3/scaling_governor:powersave

/sys/devices/system/cpu/cpufreq/policy4/scaling_governor:powersave

/sys/devices/system/cpu/cpufreq/policy5/scaling_governor:powersave

/sys/devices/system/cpu/cpufreq/policy6/scaling_governor:powersave

/sys/devices/system/cpu/cpufreq/policy7/scaling_governor:powersave

doug@s15:~$ grep . /sys/devices/system/cpu/intel_pstate/*    <<<< If driver is intel-pstate.

/sys/devices/system/cpu/intel_pstate/max_perf_pct:100

/sys/devices/system/cpu/intel_pstate/min_perf_pct:42

/sys/devices/system/cpu/intel_pstate/no_turbo:0

/sys/devices/system/cpu/intel_pstate/num_pstates:23

/sys/devices/system/cpu/intel_pstate/status:active

/sys/devices/system/cpu/intel_pstate/turbo_pct:18

Anticipated question: If there is only one PLL, and all CPU always operate at the same frequency, then why are different frequencies reported for them? Example:

doug@s15:~$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq

2186018

2315657

2308037

2254830

2111971

2127314

2169466

2152378

Answer: In any given measurement interval, the CPUs are also going into and out of various idle states, where, if the idle state is deep enough, the CPU clock is stopped. The reported frequency is the average active frequency for that processor over the last measurement interval.