Re: [gentoo-user] CPU frequency tweaks

[Mick]

Thanks Adam,

On Monday, 1 July 2019 00:03:21 BST Adam Carter wrote:

> IIRC boost states work by boosting a single core when the other cores are
> idle, so you wouldn't expect it to kick in on a -jN emerge.

I have observed on an Intel i7 with a schedutil governor, cores kicking in 
individually while compiling or running something like cpuburn, while the rest 
of the cores remain above idle.  I understand these days boost states are 
regularly used whenever the thermal budget of the CPU allows and the CPU load 
demands it.


> You could try
> closing all other programs and temporarily running -j1 as an experiment to
> see if it kicks in at all. If it doesn't work then i'd look at BIOS
> updates. Have you included the microcode in the kernel?

I've tried both single and multiple jobs loading as many as 8 threads, 
switching between performance, userspace, schedutil governors.  As far as /
proc/cpuinfo or 'cpupower monitor' indicated, the frequency never switched 
into boost and the 'cpupower frequency-info' did not show the boost state as 
active.  This is in contrast to the minimal-CD, which revs all the way up to 
3500MHz on all cores and shows the boost state as active.

The laptop has been flashed with the latest UEFI firmware available by the 
OEM.  I am also loading the microcode in the kernel, with:

CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam15h.bin ....."

dmesg shows the following:

$ dmesg | grep -i micro
[    0.622453] [drm] Loading ARUBA Microcode
[    5.759940] [drm] Loading hainan Microcode
[    6.713011] microcode: CPU0: patch_level=0x06001119
[    6.714206] microcode: CPU1: patch_level=0x06001119
[    6.715311] microcode: CPU2: patch_level=0x06001119
[    6.716330] microcode: CPU3: patch_level=0x06001119
[    6.717333] microcode: Microcode Update Driver: v2.2.

You'll notice it doesn't show "microcode: updated early to new patch_level" 
unlike what some older Intel systems of mine show right at the start of dmesg; 
mind you an AMD Kaveri system I'm running is the same.  Perhaps there is no 
later microcode for these CPU-APUs.

Here is what I suspect.  The minimal-CD is not loading any radeon firwmare, or 
running Xorg.  It may be radeon is interfering with the CPU, holding back from 
boost states in case the APU graphics needs it later on.  I could be a bug - 
I'm not sure.  I would have thought since this an old CPU, by now it should be 
working without any tweaks and any bugs would have been ironed out in the 
kernel.  :-/

I attach the diff between the minimal-CD kernel config and mine in case anyone 
can spot something in there around the options under CPU_FREQ and scaling 
drivers.
-- 
Regards,

Mick