24 Cores and the Mouse Won't Move: Engineer Diagnoses Windows 10 Bug (wordpress.com)

Longtime Slashdot reader ewhac writes: Bruce Dawson recently posted a deep-dive into an annoyance that Windows 10 was inflicting on him -- namely, every time he built Chrome, his extremely beefy 24-core (48-thread) rig would begin stuttering, with the mouse frequently becoming stuck for a little over one second. This would be unsurprising if all cores were pegged at 100%, but overall CPU usage was barely hitting 50%. So he started digging out the debugging tools and doing performance traces on Windows itself. He eventually discovered that the function NtGdiCloseProcess(), responsible for Windows process exit and teardown, appears to serialize through a single lock, each pass through taking about 200 microseconds each. So if you have a job that creates and destroys a lot of processes very quickly (like building a large application such as Chrome), you're going to get hit in the face with this. Moreover, the problem gets worse the more cores you have. The issue apparently doesn't exist in Windows 7. Microsoft has been informed of the issue and they are allegedly investigating.

Comments

The lock cycles were avg 200 us each

[Anonymous Coward]

Not 200S each, which is off by a factor of one million. But, hey.

Windows has always been unresponsive to user input

[fustakrakich]

We just don't have priority...

Re:I don't get it.

[mvdwege]

Yes, you are making exuses, that's exactly what a tu quoque fallacy is

The big lock was removed in 2011, Microsoft produced a regression on an already bad design a lot closer in history. That's a sign of incompetence, period.

Also, the Linux kernel has bad backwards compatibility, which is why things like drivers and such should be upstreamed as much as possible and built in the main tree, but Linux userland still happily runs old Unix software, so you are overstating that case as well.