Intel Posts Big Linux Patch Set For "Classes of Tasks" On Hybrid CPUs, Thread Director

[phoronix]

Phoronix: Intel Posts Big Linux Patch Set For "Classes of Tasks" On Hybrid CPUs, Thread Director

Sent out as a "request for comments" on Friday night was a new patch series out of Intel introducing the notion of "classes of tasks" for the Linux kernel so that the scheduler can make better decisions on hybrid processors like with Intel's Alder Lake processors and upcoming Raptor Lake. This also provides a more complete implementation of Intel Thread Director for Linux and may also be used as the basis for instruction set differences between the performance and efficient cores...

https://www.phoronix.com/news/Intel-Linux-Classes-Of-Tasks-TD

[Linuxxx]

This "classes of tasks" work may also prove critical for future Intel CPU generations where there may be more instruction set differences between the P/E cores such as if AVX-512 or other advanced instructions were to make a return to P cores in a hybrid configuration.

I'm not quite sure if this will actually help to implement an asymmetric ISA.

To me, it sounds like this is intended strictly for performance (IPC) reasons:

IPC can be higher on some CPUs for advanced instructions.
...
The load balancer can discover the use of advanced instructions and prefer CPUs with higher IPC for tasks running those instructions.

Maybe someone more knowledgeable on this topic can chime in...

[birdie]

Only a year too late and still without a userspace component.

[kylew77]

Scanned the email looking for "GNU' or "GPL" and didn't see any but given the linuxisms in this code base looks very Linux-centric so other operating systems will have to reverse engineer. I chatted with an OpenBSD dev on reddit awhile back about big.little design optimizations in its Kernel and they have no intentions of optimizing at this time just like they never optimized for SMT so it will be interesting to see if in the future top performance requires this Thread Director code for Raptor Lake, Meteor Lake Lake, and Arrow Lake.

[birdie]

Scanned the email looking for "GNU' or "GPL" and didn't see any but given the linuxisms in this code base looks very Linux-centric so other operating systems will have to reverse engineer. I chatted with an OpenBSD dev on reddit awhile back about big.little design optimizations in its Kernel and they have no intentions of optimizing at this time just like they never optimized for SMT so it will be interesting to see if in the future top performance requires this Thread Director code for Raptor Lake, Meteor Lake Lake, and Arrow Lake.

Never optimized for SMT? I'd say this is a dead OS in this case. HT/SMT absolutely requires optimization or otherwise your performance may tank. Consider you're running a lightly multithreaded app with e.g. 2 threads, the system is idle and instead of scheduling the app to physical cores 0 and 1, you instead schedule it to run on Core 0 and its sibling SMT/HT core. Now, instead of getting double the performance you're only (at best) getting a 30% performance increase. And there's a ton of similar use cases when SMT/HT absolutely needs to be taken into consideration. And of course you absolutely need to optimize for Numa and Zen CCX'es.

[Volta]

Only a year too late and still without a userspace component.

Still eating windows for breakfast.

[elbar]

Linux kernel has groups and something like GUI or audio has higher preference than some server IO stuff load. Kernel has also framerate or frequency under which operate which is why there is RT kernel problem or problem of pulses(frequencies) which need to setup problem via central synchronization and when there is problem, then BFS(or its successor) by KonKolivas scheduler is a no go to hardcore linux devs who don't care on Linux Desktop Market $hare.

[Volta]

Linux kernel has groups and something like GUI or audio has higher preference than some server IO stuff load. Kernel has also framerate or frequency under which operate which is why there is RT kernel problem or problem of pulses(frequencies) which need to setup problem via central synchronization and when there is problem, then BFS(or its successor) by KonKolivas scheduler is a no go to hardcore linux devs who don't care on Linux Desktop Market $hare.

An only problem here is your clueless comment.

[kylew77]

Never optimized for SMT? I'd say this is a dead OS in this case. HT/SMT absolutely requires optimization or otherwise your performance may tank. Consider you're running a lightly multithreaded app with e.g. 2 threads, the system is idle and instead of scheduling the app to physical cores 0 and 1, you instead schedule it to run on Core 0 and its sibling SMT/HT core. Now, instead of getting double the performance you're only (at best) getting a 30% performance increase. And there's a ton of similar use cases when SMT/HT absolutely needs to be taken into consideration. And of course you absolutely need to optimize for Numa and Zen CCX'es.

Well after Meltdown and Spectr OpenBSD just disables SMT by default not just on AMD64 but on ARM64 and POWER 9 too as a security concern. It is why my new laptop has an 8 core 8 thread Ryzen in it because the extra 8 threads of the higher model wouldn't get used. Michael did an article on it back in the day.

[kylew77]

Never optimized for SMT? I'd say this is a dead OS in this case. HT/SMT absolutely requires optimization or otherwise your performance may tank. Consider you're running a lightly multithreaded app with e.g. 2 threads, the system is idle and instead of scheduling the app to physical cores 0 and 1, you instead schedule it to run on Core 0 and its sibling SMT/HT core. Now, instead of getting double the performance you're only (at best) getting a 30% performance increase. And there's a ton of similar use cases when SMT/HT absolutely needs to be taken into consideration. And of course you absolutely need to optimize for Numa and Zen CCX'es.

Now I'm SURE someone will correct me if I'm wrong but I don't think FreeBSD, the biggest *BSD distribution, optimizes for Big.little architectures on ARM64. I found an article from 2021 saying it didn't support the notion of heterogenous architectures https://bugs.freebsd.org/bugzilla/sh....cgi?id=257641 I don't know if that has changed in 13.1 Release since then. If Open and FreeBSD don't support the notion then I would bet money that NetBSD doesn't either.