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

I don't get it.

[fuzzyfuzzyfungus]

If there is an issue that keeps process termination and cleanup from being properly parallelized; I can understand why that might cause unexpectedly poor utilization of additional cores for computationally intensive tasks that also massacre lots of processes; but why would that cause the GUI to stop responding?

Unless moving the cursor also depends on terminating a bunch of processes; and hangs until that task is finished, wouldn't the inefficiency imposed on the build process be expected to keep the GUI more responsive; by preventing it from occupying as much CPU time as it otherwise would?

Am I just confused? Does keeping the desktop and cursor drawn actually involve lots of time sensitive process killing? Does this indeed not make sense?

Re:I don't get it.

[Rutulian]

It's easy to criticize from the outside, but the Linux kernel has historically had kernel locks that created similar problems, such as the "big kernel lock", removed ca 2011 (ie: not ancient history).
https://kernelnewbies.org/BigK...

As noted in the article, this particular locking problem appeared in Windows 10 and wasn't present in Windows 7, so the balancing acts between the fine-grained locking mechanisms, thread performance, and backwards-compatibility are clearly challenging to maintain. Not excusing; just observing. Windows has never been known for it's ability to support massive numbers of parallel threads, so it is not surprising that previously overlooked problems can appear or become exacerbated in these situations. Many people, even here on Slashdot, laud Microsoft for the generally excellent backward- compatibility in Windows, and criticize the Linux kernel for being generally horrible at it. But here you go, a pretty nice example to illustrate that backwards-compatibility has a cost.

Re:I remember BeOS

[adolf]

I was accomplishing this on 486DX2 hardware using OS/2 in ~1994, and by 1995 on a P120.

Several years ago I stopped by a buddy's retail establishment. He was transitioning network to Ubuntu on more modern hardware (with OS/2 in a VM), but still had an old and crusty OS/2 machine (probably a K6-2, but maybe a DX4) on the bench by the back door.

This was the last time I ever saw such a thing in the wild.

It was remarkably snappy doing normal, productive things -- scanning documents, browsing web pages, writing and viewing proposals -- just like it was when it was built. (And what window tearing?)

Sometimes I think that the more abstraction layers we add, the slower things get. I think this coupled with programmer laziness (and/or pay based on lines of code), makes human-interactive things continue to behave just as slow as they have been for ~20 years.

Do we even use accelerated 2D desktop graphics anymore, or are we completely back to the bad old days of every application drawing into a dumb framebuffer?