Intel HFI To Premiere In Linux 5.18 For Improving Hybrid CPU Performance/Efficiency

[birdie]

That seems fairly trivial though, once the hardware capabilities are exposed. I'm not sure why it would be difficult, anyway.

Microsoft had quite a lot of issues with Windows 11 and the Intel Thread Director which took them many months to resolve. And Microsoft has all the money in the world and talented engineers. And Windows is first and most a desktop OS.

Linux is mostly driven by corporations which use Linux on the server where the heterogeneous ADL uArch is not on the radar yet and even if Intel releases ADL server CPUs, an average server has quite a different workload and no one will cry foul if their server tasks are moved across P/E cores.

[birdie]

I wonder why couldn't that daemon run in kernel space in the kernel thread just like how RCU or idle_inject run there. A daemon in userspace would be unoptimal.

If there's an API to instruct this kernel thread, I'm fine with that but I'm not sure if it's necessary or will be implemented. For instance all OOM daemons for Linux are user-space applications and the kernel developers made it clear they wouldn't implement the feature in the kernel space.

Windows is a graphical operating system down to the core, so it performs well on desktop (but has some struggle on servers).
Linux is a general-purpose operating system, so it performs well on servers but maybe not so well on desktop.

Exactly.

What he means is that under Windows the active window/task is given higher priority in the scheduler, the kernel can not do that on its own since it does not know what a window is, and less so which one is in focus.

Exactly.

[coder]

Linux always gets the most boring names...

I know it doesn't matter, but seriously to the average consumer it doesn't sound cool.

"Hardware Feedback Interface" or "Thread Director"?

"Thread Director" is the name of the hardware feature in Intel's Alder Lake CPUs. Not only is it not Linux-specific, Windows 11 was the sole OS to support it at the time of the CPU's launch.

Also, Windows has plenty of boring infrastructure names.

[middy]

What he means is that under Windows the active window/task is given higher priority in the scheduler, the kernel can not do that on its own since it does not know what a window is, and less so which one is in focus.

is that because its "display server / compositor" is able to communicate with the kernel and tell it what it "see's" to scheduler better? like "this window has focus and full screen, give it higher priority on a "p" core, and these windows are minimized / background, switch them to "e" cores." if so could this be fixed with a wayland protocol and drm improvements?

Microsoft had quite a lot of issues with Windows 11 and the Intel Thread Director which took them many months to resolve. And Microsoft has all the money in the world and talented engineers. And Windows is first and most a desktop OS.

Linux is mostly driven by corporations which use Linux on the server where the heterogeneous ADL uArch is not on the radar yet and even if Intel releases ADL server CPUs, an average server has quite a different workload and no one will cry foul if their server tasks are moved across P/E cores.

i can believe that seeing amd's lack of desire to bring cppc support to linux with their zen 2 and above processors. it took valve of all people to "encourage" them to do it... much like it took valve to improve amd's own gpu drivers with creating the aco shader compiler...

[coder]

and even if Intel releases ADL server CPUs, an average server has quite a different workload and no one will cry foul if their server tasks are moved across P/E cores.

I guarantee there are people who care how good the heterogeneous scheduling is. Whether it's about reducing transaction latency, maximizing throughput, or maximizing transactions per Watt, there's nothing about servers that makes effective heterogeneous scheduling irrelevant.

However, we already know Sapphire Rapids won't feature E-cores. So, that leaves only the corner case of Xeon E-series CPU that are basically desktop CPUs with a few extra features enabled to potentially feature any little cores in this upcoming generation.

[coder]

i can believe that seeing amd's lack of desire to bring cppc support to linux with their zen 2 and above processors. it took valve of all people to "encourage" them to do it... much like it took valve to improve amd's own gpu drivers with creating the aco shader compiler...

It's not easy to grow an engineering team rapidly, yet that's exactly the challenge AMD has been facing. In time, I think they'll get on top of their game, but they were starting from a very low base and have undoubtedly been swamped by requests and issues from all their new customers and markets they're trying to break into.

[partcyborg]

I guarantee there are people who care how good the heterogeneous scheduling is. Whether it's about reducing transaction latency, maximizing throughput, or maximizing transactions per Watt, there's nothing about servers that makes effective heterogeneous scheduling irrelevant.

However, we already know Sapphire Rapids won't feature E-cores. So, that leaves only the corner case of Xeon E-series CPU that are basically desktop CPUs with a few extra features enabled to potentially feature any little cores in this upcoming generation.

IIRC the linux scheduler prior to CFS tried to do fancy realtime scheduling adjustments, but it turned out that outside of some extremely edge cases pure fair scheduling was almost universally better

[milkylainen]

If we can invent another acronym, surely it must solve all the problems in the world...?
I bet the biggest department is one containing the 3 or 4 letter acronym creators...

[middy]

It's not easy to grow an engineering team rapidly, yet that's exactly the challenge AMD has been facing. In time, I think they'll get on top of their game, but they were starting from a very low base and have undoubtedly been swamped by requests and issues from all their new customers and markets they're trying to break into.

myself, i do have a amd 5800x and a amd 6900xt. for awhile i've felt that the only reason why amd open sourced their products was because they wanted someone else to do the work for them. which i guess is fine. its better than not open sourcing and still doing nothing because at least the community at large can do something. like valve. but as someone who drops a good chunk of their money for their stuff, its beneficial when the actual hardware producer cooperates in open source as well because its nice having the people who designed the hardware as typically, they know a thing or two more about how it works. nevertheless i am happy to see amd increasing their linux developer base. i can understand amd being financially strained and some costs had to be cut. as long as they keep giving linux special love on the desktop like they do with windows i'm happy.

[F.Ultra]

is that because its "display server / compositor" is able to communicate with the kernel and tell it what it "see's" to scheduler better? like "this window has focus and full screen, give it higher priority on a "p" core, and these windows are minimized / background, switch them to "e" cores." if so could this be fixed with a wayland protocol and drm improvements?

I'm unsure on exactly how this works technically on the WIndows side, but there is nothing preventing any compositor to to the same on Linux as long as the kernel implements some way for userspace to communicate such things to it. That said, there is a strong emphasis in the Linux camp to solve this with heuristics and automation so we have to see where this will all go.

an average server has quite a different workload and no one will cry foul if their server tasks are moved across P/E cores.

Now I cannot speak for other peoples sever needs but for all the servers that I have ever managed there would be death threats issues inside the company if tasks where moved across P/E cores, which most likely is also why we don't see Intel releasing this architecture on any of their Xeon chips.

And when/if it comes I'm quite certain that there will be no automagic scheduling of them and instead people will want to manually assign certain tasks or certain threads of certain tasks to the E cores.