- cross-posted to:
- hardware@lemmy.world
- cross-posted to:
- hardware@lemmy.world
You must log in or register to comment.
During the course of our testing, we observed that Windows 11 was scheduling workloads on the 9700X in a manner that would try to saturate a single core first, by placing workloads on each of its logical threads.
🤦♀️
it’s obviously a scheduler/p-state bug in windows, look at the Linux performance
so, basically, the os isn’t tuned for the new chips yet.
the 2nd threads on smt-enabled cores are supposed to get hit last.
It’s an easy fix, sure.
But there are 3 manufacturers for them to schedule for. It should be ready way before anything ships.
Copilot and ads taking up development cycles
Actually, yeah, probably. CPU scheduling isn’t the shiny new thing, nor something that gets that sweet, sweet monthly recurring revenue. So, it doesn’t get prioritized.
Microsoft always operates like this. Whatever bullshit management demands for marketing purposes takes the resources away from basic stability and quality improvements. Sometimes this results in quite predictable disaster:
There should be no need for tuning, tweaking, or optimizing on functionality this basic.
If you ask the processor, it will spit out a graph like this telling you what threads/cores share resources, all the way up to (on large or server platforms) some RAM or PCIe slots being closer to certain groups of cores.
For values of “new chips” that include 20 year old ones. Foster was released 2001, the chips were single-core but you could have up to eight on a board so it’s still multi-core SMT. First on-die multi-core SMT seemed to have been Paxville, 2005.
Or maybe Windows server has a proper scheduler and they never bothered bringing it to desktops?
This is shockingly stupid. SMT has been a thing on x86 long enough for it to be able to buy it’s own alcohol and yet somehow the windows scheduler STILL can’t fucking deal with it?
I’m not a kernel-level developer or anything but I mean, at some point you have to wonder how fucking trash windows kernel internals are that this problem keeps happening over and over and over and…
deleted by creator
