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.

[Anonymous Coward]

The Windows GUI interface actually uses a separate process to update the mouse on the screen. Due to various historical reasons (compatibility with old applications, mostly), it was required to recycle this process every time the mouse moved, as the process could get a memory leak (which couldn't be fixed properly, in order to preserve compatibility with the aforementioned applications). Therefore, every time the coordinates of the mouse change, the process has to be killed and replaced, therefore putting it through the same lock that this build process is hogging. Combine that with the 200 second delay to get through the lock, and the responsiveness is easily explained.

It's worth it to keep compatibility with the "After Dark" flying toasters screensaver, though.

Re: Not just when closing a program

[viperidaenz]

Android is dropping to lower-res/fewer colors to accelerate the transition

Or did it swap the high-res texture for a low-res one to save memory while it was not in use?

GPU's have been able to do 32bit acceleration for a long time.

Semi-OK gaming video cards that didn't support DirectX 9 couldn't run Vista Aero because it used the DirectX 9 API, required hardware based Pixel Shader 2.0 (not emulated in the driver) and at least 128MB of RAM. Not because of bit-depth.

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.