CPU frequencies and thread scheduling issue on Raptor Lake

[e8root]

Two issues:

1. Frequency change despite disabling SpeedStep in UEFI
In Win11 I get locked 5.4GHz on P-cores and 4.3GHz on E-cores.
On Linux CPU-X shows 3.5GHz which can change to 5.4GHz but it has to be almost 14 threads to get consistently 5.4GHz. For single thread it will say 3.5GHz.

I managed to tweak kernel config (with genkernel + menuconfig) to make kernel which runs at 100% but it didn't resolve second issue with scheduling.
I tried disabling intel_pstate and some other command I forgot to note down regarding idle clocks and choosing default governor but it didn't do anything. Since I managed to make kernel which works correctly this issue is virtually resolved. I might however need this intel stuff for this second issue so maybe not quite resolved... then again I disabled lots of stuff and don't know yet which is needed or if issue lies elsewhere.

Note: I do get kenrel message: ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
Looks like something systemd does but I am not sure yet what it is really about.
Most info found in google refers to tools I do not have or some directories in /sys which I do not have.

2. Linux doesn't seem to care for two core types at all. It sees cpu_atom and cpu_core in /sys/devices and cpus file inside show correct core allocation but thread scheduling completely ignores this difference in core types and because Linux doesn't seem to preemptively shuffle threads around like Windows always does it results in random results in benchmarks. If for example Geekbench schedules to P-core then result is ok (after forcing CPU frequency... which is another issue) then result is ok but if it lands on E-core then result is pretty bad.

My kernel is normal gentoo-kernel 6.7.6... or 6.6.13 cause I did specifically test older non ~amd64 kernel I built during system install just to be sure I didn't misconfigure anything in /etc/portage or elsewhere.

I do not see cpufreq in eg. /sys/devices/system/cpu/cpu0
I do not use SpeedStep and I do not want any frequency changes as so far on none of the systems I tested if it reduces power consumption I saw any differences between extremes like idling 800MHz with core parking and lower voltage vs idling at max clocks without core parking and increased voltage. That last voltage part did show minuscule difference but even then (and most importantly for my system) it was negligible and in order to make system stable I would need more fine control over clock/voltage curves and otherwise I would need to drastically increase load power consumption to avoid system crashing at low/medium load... actually I overclocked CPU and at the same time reduced power consumption by just using fixed voltage that is reasonable for 5.4/4.3GHz. Dynamic frequency scaling doesn't work in practice on any system I tested in on and it shouldn't be needed for anything.

In fact with clocks spinning at 100% it is possible to get proper performance characteristics even in Windows 10 which doesn't even support P/E-cores just because Windows will schedule threads to cores with higher clock and especially foreground applications. Win10 only have issues with Alder/Raptor Lake because by default cores idle at 800MHz and Windows takes current frequency and not maximum frequency for choosing the fastest core to schedule thread to so it often schedules threads on E-cores - yet it would still jiggle its way around to P-cores for most of the time and especially with heavy background activity. I mention this because I would at least expect this behavior from Linux even if it didn't had bloody idea about difference between P-cores and E-cores but this doesn't seem to be the case - it seems to be aware it has two core types and still schedule threads like it didn't made any difference to it.

Anyone has any idea how to resolve these two issues?

ps. I do not use and never ever intend to ever use HyperThreading so this can of worms is sealed tight. CPU is Core 13600KF
_________________
Unix Wars - Episode V: AT&T Strikes Back

[pietinger]

[e8root]

P/E-core issue was solved by enabling Speedstep in UEFI
It apparently has something to do with INTEL_HFI_THERMAL sensor which interface in Linux is used to query information about hardware threads from the CPU. After verifying its enabled in default kernel config I figured Speedstep might have something to do with it.
Now I am wondering if Windows could did that without Speedstep... but then again Windows always seemed to schedule threads on P-cores so not sure. Either they do things differently or it just did its own scheduling. I'll do some more tests in Windows between Speedstep on and off but for now I do not want to look at Windows

As for issue with clocks they change but performance seems good therefore my conclusion is that all of the low benchmarks results were from scheduling on E-cores.
I will tinker with governors just to know how to set them up and check if Linux show the same strange results as Windows where idling at 100% CPU frequency uses the same power as idling at lower clocks. For now I managed to disable idle states and this did increase clocks to 100% but also considerably increased idle power consumption. In this case it is expected behavior from clocks but I think the issue is that disabling idlestates just prevents Linux from idling CPU at all. Not using any idle states is for example why Win98 had higher idle power consumption than Windows NT. At least this is my current assumption and it all is to be verified.

When it comes to HyperThreading it has multiple issues with it and why Intel is dropping it.
Just for curiosity sake I will recheck how scheduling works on my 13600KF with HT on Linux and if it has the same issues I always observed with HT on Windows where background tasks could reduce performance of cores allocated to foreground tasks from 100% to ~65%. There is a way to schedule background tasks in such a that issues wouldn't happen but I never observed this expected optimal behavior in Windows. I remember I did check system with SpeedStep and definitely used Speedstep on Core i9 9900K along with HT but then again these things can change over time and improve so it might be worth checking even if this won't be an issue for long.

In either way IMHO it is always worth being very pedantic about these things and always do sanity checks including verifying expected scheduler thread assignments and comparing performance to references. Here I just got to benchmark after using Gentoo for less than a month and I barely feel system is installed enough to worry about such things. I should check this earlier because I did quite a few builds and the way scheduler worked was not optimal at all and increased build times for lightly threaded parts of emerge by quite a lot by randomly using E-cores. In fact with 8 E-cores and 6 P-cores there was more probability to use E-core...
_________________
Unix Wars - Episode V: AT&T Strikes Back

[pietinger]

Maybe it fits here ?

https://www.phoronix.com/news/Linux-6.9-APIC-x86-CPU-Topology
_________________
https://wiki.gentoo.org/wiki/User:Pietinger

[pietinger]

News about Intels P-/E-cores: https://www.phoronix.com/news/Intel-P-State-Asymmetic-Hybrid
_________________
https://wiki.gentoo.org/wiki/User:Pietinger