Linux 6.5 To Boast Improved Handling For Intel Hybrid CPUs With Hyper Threading

[phoronix]

Phoronix: Linux 6.5 To Boast Improved Handling For Intel Hybrid CPUs With Hyper Threading

Going back to last August were Intel patches to help Intel hybrid CPU handling on Linux by avoiding unnecessary task migrations within SMT domains. Coming this summer those Intel patches are finally set to arrive with the Linux 6.5 kernel cycle...

https://www.phoronix.com/news/Linux-6.4-Avoid-Unnecessary-SMT

[Joe2021]

Wouldn't it be best to remove HT from silicone completely, since with bit.LITTLE-Designs this approach is quite pointless as you have enough threads with E-Cores anyways? This would speed up the P-Cores even more by simplification of design while also getting rid of some vulnerabilities AFAIK...

[Mitch]

Wouldn't it be best to remove HT from silicone completely, since with bit.LITTLE-Designs this approach is quite pointless as you have enough threads with E-Cores anyways? This would speed up the P-Cores even more by simplification of design while also getting rid of some vulnerabilities AFAIK...

I don't see how they'd get in the way. You can simply not use them. According to what I've read, HT siblings of saturated threads are last in priority. So in theory, they'd only ever get queued once everything else gets filled up.

I'm not saying SMT is worth keeping, I'm not sure the costs of it in. But assuming it's not too expensive to keep around from a manufacturing perspective, they seem like they're only a positive, and a rather large one, if used properly by the scheduler.

[jbowen]

phoronix if you still have a RaptorCS P9 board, it would be interesting to see before/after results on them with SMT > 2 to see if there are any regression or anything else unexpected.

[avis]

Wouldn't it be best to remove HT from silicone completely, since with bit.LITTLE-Designs this approach is quite pointless as you have enough threads with E-Cores anyways? This would speed up the P-Cores even more by simplification of design while also getting rid of some vulnerabilities AFAIK...

HT/SMT is relatively cheap to implement and bestows an additional ~30% performance benefit. Why would you remove free performance?

[Joe2021]

HT/SMT is relatively cheap to implement and bestows an additional ~30% performance benefit. Why would you remove free performance?

This becomes less and less true with more and more E-Cores, as the CPU is expected to run in a thermal limit anyways.

If there are plenty of E-Cores, it is better to spent the available energy budget on them. This could even lead to the situation of ignoring P-Cores in favor of E-Cores to result better performance, which is true when E-Cores do more calculations per Joule AND energy is your constraint.

On the other hand, it is favorable to have P-Core being as fast as possible, for single- (or few-) threaded workloads, so reducing complexity by removing SMT could help in that regard.

Additionally it might be interesting to see the performance gains when you can switch off several mitigations of the kernel. Those, btw, also eat energy, and as energy is the primary constraint....

[aufkrawall]

HT is a super effective way to fight all sorts of per core utilization bubbles, will you stop picking on it...
Also, a CPU without HT will always have a shorter lifespan with regard to proper gaming performance compared to one with HT. PC games tend to shit all over CPUs with overhead these days, even 4 logical cores per physical one might be beneficial for such cases...

Example: Think of the Steam Deck. Too narrow power envelope for more cores (at least in x86 reality) and HT helps to maintain playability of recent games like The Last of Us. Performance of that game just dies if you don't provide it with enough (logical) cores.

[Joe2021]

HT is a super effective way to fight all sorts of per core utilization bubbles, will you stop picking on it...
Also, a CPU without HT will always have a shorter lifespan with regard to proper gaming performance compared to one with HT. PC games tend to shit all over CPUs with overhead these days, even 4 logical cores per physical one might be beneficial for such cases...

Example: Think of the Steam Deck. Too narrow power envelope for more cores (at least in x86 reality) and HT helps to maintain playability of recent games like The Last of Us. Performance of that game just dies if you don't provide it with enough (logical) cores.

Well, no, I won't. You are a) still sticking to the assumption that there are too few cores available which is not true for most use cases with 16 E-Cores, and b) you assume that cores consume energy, which is wrong - calculations consume energy. Hence it is more efficient to use 4 E-Cores instead of a single 4-way SMT-P-Core, and if this approach is more efficient, it is necessarily faster when there is a narrow power envelope.

[avis]

Joe2021

I've not seen tests comparing performance of HT siblings of P-cores vs E-cores. I don't think it's all so straightforward as you make it sound.

Check this vid for example. E-cores no matter how you use or slice them, make the game run slower and the system consume more power than when you only have P-cores.

[aufkrawall]

Check this vid for example. E-cores no matter how you use or slice them, make the game run slower and the system consume more power than when you only have P-cores.

Games that spawn lots of threads, e.g. CP77 or Spiderman Miles Morales with maxed out RT, get faster with active e-cores.
Also, Windows has utterly dumb core parking configuration for Alder and Raptor Lake CPUs, even those without e-cores. But it hurts the latter more, as utilization of single cores is lower and so parking happens more often. It's baffling to not read about this more often, it can cause frame time spikes of several hundreds of ms in games with very low CPU load. Breathtaking incompetence by Intel & Microsoft...