Slashdot Mirror
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.
Well... there's your problem.
being the only OS I've ever seen in my life move a window around screen w/o tearing. Yeah, it doesn't make much difference, but you'd think in 2017 my quad core CPU and 8 gigs of ram could do what a 400 mghz AMD K6 did in 1996 with 512 mb ram.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
That could be related to the hardware acceleration. If I had to guess, the Windows desktop would need to wait for the game to release it's GPU resources and load its own in to the GPU memory.
Back in the XP days, going from game to desktop was very quick, but going from desktop back to game was very slow. When Vista came along, the Os started using the GPU to accelerate the desktop. Made it slow both ways
I didn't believe that number for the first microsecond. Where was your brain? Stuck on "easily explained"?
From the original:
Even Microsoft would notice 24 cores sharing a 200 s group hug.
If the question had been "total number of photons emitted from the sun over the last 4.3 billion years", I would accept +/- six orders of decimal magnitude as constituting a reasonable effort. In this case, not so much.
Soo, that means that a simple DoS is possible via old-school fork bombs ? In 2017 ? Well done Microsoft !
More specifically, why are OSes not designed, and computing hardware not designed, so that the GUI cannot be slowed down by other slow processes, process switching, or I/O / virtual memory thrashing.
That's why OSes such a Linux (not even over-optimized for responsivity) have an entire zoo of CPU schedulers and IO schedulers.
(with BFQ being the latest popular IO scheduler for responsivity),
and linux specifically has hte non-POSIX "CGROUPS" extension that enables it to arrange the various processes into a tree hierarchy with each node supporting its own scheduling tactics between its childern (see demos of 256 GCC compiler jobs launched in parallel and the GUI still being responive).
(That's also part of the reasons why modern complex manager like systemd are getting popular, they have modules to handle all this : session, seats, etc. concepts that POSIX lacks)
BeOS was an OS whose entire purpose was exactly that : no matter what, keep UI responsive and avoid media stuttering.
(Well, running initially on architecture with less expensive context switches did also help a lot).
The UI and user input devices should be a completely separate set of processes and memory than the rest of application processing.
Actually, in most OSes, they already are.
It should operate as a service, through data pipelines, to the rest of the applications.
That's a tiny bit less obvious. Some graphical tool-kits run their UI in the main thread.
Some software would need to have the processing moved into a background thread or process.
WebApps are an obvious counter-exemple where the UI is an entirely different process (And depending on where the sever is executed - even different machine).
Or failing that, certain aspects of GUI, such as program kill controls, should be highly prioritized over pretty much everything else.
Again, slow and over-used everything else should not slow the UI and user input processes.
And then you'd complain that any complex calculation (compression of a video) takes ages, because the process is constantly being interrupted to give time to your GUI and mouse (i.e.: to the various driver and daemons and libraries processing USB and/or Bluetooth) even if they don't need.
Balancing responsivity (i.e. constantly interrupting everything just to be sure that everyone get their share of CPU cycles and IO) and performance (running as much un-interrupted as possible so the task finishes as fast as possible) is a complex dark art.
But, yeah, Windows is significantly worse at this compared to everyone else.
Which also explains you'll never see any deployment of Windows on the TOP500 (it's nearly Linux all the way, with a few excption like BSD - i.e. other Unix-type of OSes), and Azure is the only known cloud running it.
It's also why Linux is popular in most embed systems (modems, routers, smartphone, tons of IoT gizmos, smart TVs, etc. - basically nearly anything with a CPU that is not a desktop computer is likely to run some Unix-like kernel like Linux)
It's not that Linux is magic, it's that Windows is *THAT* awfully bad at anything.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]