Folding Forum

Hi all,

Title says it, on a PC with both P-cores and E-cores, such as 12700K, workload always got scheduled to E-cores, wasting at least 70% of available power.

Setting fold power or core slot has no effect, the only workaround is to set "processor affinity" for the CPU workload process to disable all E-cores of that process. However the process respawns for each new workload, forcing manual intervention every time.

Apparently this issue is only found on Windows 11 22H2, last build did not have this problem.

----

EDIT: somehow I believed I had 11th gen when posting, weird.

On big.LITTLE CPUs, the first thing to do is to manually set the number of threads of the CPU folding slot to match the number of threads of P-cores.

If Windows is still messing around with its scheduler after doing this, you might need a tool like Process Lasso to handle the affinity management automatically.

Hate to be that guy but intel 11th gen processors don’t have big core, little core architecture.

https://www.intel.com/content/www/us/en ... tions.html

Only 12th gen and up have that architecture.

https://www.intel.com/content/www/us/en ... tions.html

Spongebob25 wrote: ↑Mon Dec 19, 2022 4:29 am Hate to be that guy but intel 11th gen processors don’t have big core, little core architecture.

https://www.intel.com/content/www/us/en ... tions.html

Only 12th gen and up have that architecture.

https://www.intel.com/content/www/us/en ... tions.html

Weird, I have 12700K but when I wrote the post, I magically believed I only had 11700K and 11th gen.

toTOW wrote: ↑Sun Dec 18, 2022 9:50 pm On big.LITTLE CPUs, the first thing to do is to manually set the number of threads of the CPU folding slot to match the number of threads of P-cores.

If Windows is still messing around with its scheduler after doing this, you might need a tool like Process Lasso to handle the affinity management automatically.

Setting core slot has no effect, apparently this is a Win11 22H2 behavior.
I'm setting core affinity manually at this point, hopefully a future FAH or Windows release will fix it soon.

I heard that Windows scheduler is based on process priority to assign to P-cores or E-cores ... try to set FahCore priority to Normal in task manager and see if that helps ...

toTOW wrote: ↑Tue Dec 20, 2022 7:55 pm I heard that Windows scheduler is based on process priority to assign to P-cores or E-cores ... try to set FahCore priority to Normal in task manager and see if that helps ...

Doesn't work, From what I understand it's a hybrid between white listing and foreground/background switching.
FAH CPU worker process is always background and has not been whitelisted, therefore it always get stuck in E mode unless you manually change affinity, not priority.

Background and foreground processes shouldn't have anything to do with affinities. It's only based on process priority in Windows scheduler and some black magic that only Microsoft understands.

As stated multiple times in threads about big.LITTLE CPUs, the fix is to set the CPU slot to use the number of P-cores that is present in the system, and if it isn't enough (or Windows scheduler is too dumb to understand), to use Process Lasso to automate the process of setting affinities of FahCore processes to P-cores.

Using a CPU without all this big.LITTLE mess is still the best solution ...

toTOW wrote: ↑Sat Jan 21, 2023 9:28 pm Background and foreground processes shouldn't have anything to do with affinities. It's only based on process priority in Windows scheduler and some black magic that only Microsoft understands.

As stated multiple times in threads about big.LITTLE CPUs, the fix is to set the CPU slot to use the number of P-cores that is present in the system, and if it isn't enough (or Windows scheduler is too dumb to understand), to use Process Lasso to automate the process of setting affinities of FahCore processes to P-cores.

Using a CPU without all this big.LITTLE mess is still the best solution ...

Yep did more research on this and found a slightly better workaround, there isn't much documentation available for this feature as it's pretty new, only interview articles.

The new scheduler algorithm is P and E cores aware and decides on whether to use P cores based on a number of factors. The 12th gen Intel chips will "recommend" scheduling placement based on instruction set features used, the scheduler is pre-trained by MS to place workload based on this recommendation and the overall usage scenario.

One interesting aspect the scheduler uses is whether the process is foreground or not. Placing it in the background automatically switches it to E cores.

This is a problem for certain workflows that some power users may use, for example building/rendering a project, then either write some emails or just browse youtube. The scheduler may decide to put the browser on P cores and put the heavyweight rendering software on E cores, which is counterproductive.

Or if the production software has a process for UI/foreground works, but spawns another process for rendering/background works, the heavyweight background process will never have the "foreground" status since it has nothing upfront.

Currently there is a way to disable this foreground-based switching, by settings - system - power - power mode to best performance (not the power plan in control panel)

One switch to universally disable this behavior is not granular enough, but other workarounds are not persistent. MS needs to implement smarter detection of those scenarios, or give users consistent settings to customize.

For Applications that start at a low/idle process priority there is another workaround to stop Windows from pushing it to E cores as background load: increase process priority "Above normal" (or higher). FOH starts at priority 4, regardless of what you set in its own preferences, so you can use Task-Manager or Process Lasso to change that if you need to use a power PLAN or MODE other than the combination of "Balanced" (plan) + "Best Performance" (mode).

Curiously I was quite sure that Windows only pushes INTEGER load to E cores in that manner (E cores are much worse at FLOATING-POINT) and assumed that FOH would use FLOATING-POINT operations?! But looking at the CPU power usage and Windows pushing to E cores behavior seems to suggest that FOH uses INTEGER for those work units I got yet.

F@h uses floating point extensively, so your assumption about the Windows scheduler is apparently wrong. From others who have looked into this it appears Windows primarily bases it push of F@h processing to E-cores based on it being run as a background process.

The "background" part was a given. But Windows does not push all background load to E cores.

The applications I observed being pushed to E cores were Integer based while something like Cinebench (floating-point) is not pushed to E cores. That made sense, because E cores a good at Integer, but bad at floating-point.

If my Work Units really use floating-point then I assume they are pushed to E cores because of their low/idle process priority (in combination with being "background" load). Especially knowing how changing said priority also moves them back to P cores.

If the "Folding Core Priority" option worked then it might also help with this issue. But in its current state F@h uses low/idle priority 4 regardless of what is set there.

I think Folding Core Priority has not been working since FAHCoreWrapper was introduced. I think the client sets priority on on the wrapper, and the actual core doesn’t inherit the priority.

I'd like to bump this thread.
I have a i9-14900kf, which is 16 E threads, and 16 performance threads. My advanced priority setting is set to higher.
No matter what, even if I tell it to use 32 threads; it will only use 16 threads of efficiency cores and not touch the performance cores.
I have used other applications which were able to use all the cores, so I know its possible.