LinkBack URL
About LinkBacksRead more.Utility papers over Windows Kernel issues, CPU almost doubles perf in some tests.
Read more.Utility papers over Windows Kernel issues, CPU almost doubles perf in some tests.
Wow! Nice catch
Scary that it wasn't Microsoft that caught this. Hopefully MS will be embarrassed enough to get a fix in the Windows 10 1903 update; March isn't that far off!
But then I want one to run Linux on, perhaps there aren't that many users affected.
I'm still not sure what the actual problem is for MS to fix? It sounds like they've found a workaround but they don't know why it works. Kind of reminds me of the early days of multi-core processors when we did the same.
So it seems that essentially AMD needs to work with Microsoft to get a kernel level fix so that the cpu works as intended.... so why didn't AMD pick up on this before release, surely they've got a better understanding of their cpu and better testing tools than the 'home user'.
I thought they did, and called it "game mode".Originally Posted by LSG501
Why should AMD have to fix Microsoft's bugs? For all we know AMD may well have passed on the info and example hardware to Microsoft to reproduce and fix the issue, but at the end of the day the owner of the buggy code has to fix the buggy code. AMD don't control Windows.
I never said they should 'fix' the issue for MS but clearly working together will be the most efficient way of fixing it. I get the feeling from that video that AMD hadn't seen this in house or they would have worked with MS (like they've been doing with game companies) to get it working properly purely because no company in their right mind would want negative reviews coming out if it's something that can be fixed. This fix would essentially encourage more people to buy their product and MS also isn't so evil as to not want to fix something that could/would also be affecting their server OS (it was mentioned in video that some server loads are affected), which is a BIG part of their current profit margin...
I don't think MS are evil, more like incompetent and uncaring.
Server and workstation loads are almost all running on Linux so AMD's profit margin there should not be affected in a market of "sell us one box, oh good it works here's an order for another hundred".
Corky34 (03-01-2019)
For all we know they did, or at least tried to. For all we know AMD could have contacted Microsoft and got little more than shrugs, the scheduler isn't something most developers would feel comfortable with 'fixing' especially as most of the developers who originally worked on it have probably moved onto new pastures years ago.
Yea, ^^^That^^^ 100%.
I'd throw a very rough guess at issues where the scheduler sticks associated threads on different NUMA nodes. IIRC there was a similar issue unearthed when Ryzen first launched and associated threads were scheduled on different CCXes, which AIUI (although I'm a long way from an expert on threading and hardware) meant those threads were almost constantly missing in the L3 cache, forcing a fetch across the fabric. And istr people also claiming that the Windows scheduler would sometimes "bounce" a thread between cores, and if those cores were on different CCXes this would also lead to constant L3 cache misses and a big performance penalty.
In fact, pretty much every performance issue I've seen with Ryzen has come down to "you need to be very careful about thread scheduling". If you hit the fabric at all during a fetch you're taking a significant latency penalty.
Happy to be corrected but SFAIK it's more to do with the windows scheduler mis-identifying the amount of nodes within NUMA (or is it UMA?), basically the scheduler thinks there's, like, 16 cores whereas Windows itself, or something higher up in Windows than the scheduler, sees all 64 cores. That results in Windows trying to assign the threads to 64 cores and the scheduler trying to juggle those threads between 16 core, it's basically spending half the time swapping threads between each NUMA (or UMA) node each with 16 cores.
Also it seems, from reading the Level1Techs article, that this issue was introduced when Microsoft patched Windows to support Xeon V4 (maybe V3) something like 2-4 years ago so it goes to show how messing with the scheduler can really screw things up.
Um... I never said anything about what was running what but when you basically make an unnecessary dig at microsoft it does shows a level of negative bias towards MS. And to be fair they can't be that incompetent (and before you say it the updates glitches were 'fringe' usage scenarios or down to Apple being Apple with their software when you look into it) when they had/have the most valuable company in the world based on share prices....oh wait I missed the name....
It's not negative bias towards MS IMO, yes when some people slate MS it's just bandwagoning but there are actually very valid reasons for people taking a dig at MS, they really are that incompetent, and that's without touching on the anti-competitiveness of the past, the embrace, extend, extinguish ethos of the past that i personally suspect is still very much alive, and the current awful state of updates.
You probably didn't watch the attached video... It isn't an AMD issue, it is Microsoft that is doing it wrong.
I'm not even surprised that ms didn't catch this. Its kinda matches up with their reputation these days.
"A society grows great when old men plant trees whose shade they know they shall never sit in."
Actually I did hence why I said AMD needs to work with Microsoft to get it fixed.... AMD can't fix MS code but they can work with MS to speed up a fix.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote