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.
๐คฆโโ๏ธ
this post was submitted on 10 Aug 2024
135 points (97.9% liked)
Technology
58303 readers
16 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
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
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.....
Or they just found out that Windows process scheduler is still broken beyond repair. If you look at the benchmarks on GNU/Linux performance is all there. For example see Phoronix benchmark