24-core CPU and I can’t move my mouse

HUP cikkturkáló

This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching – sometimes locking up for seconds at a time.

So I did what I always do – I grabbed an ETW trace and analyzed it. The result was the discovery of a serious process-destruction performance bug in Windows 10.

A teljes cikk itt olvasható.

( vl v | 2017. 07. 11., k – 10:31 )

Nincs itt kérem semmi látnivaló. A Windows az már csak ilyen - tessék rendeltetésszerűen használni (egyfelhasználós desktop cucc, az én házam az én váram, az én gépemen én vagyok az úr, reggel felkelsz, bekapcsolod, használod - nem több júzerrel!, este kikapcsolod, csókolom), arra, amire kitalálták, és nem lesz vele gond. A baj mindig azokkal van, akik mindenáron le akarnak térni a kijelölt ösvényről (aka One Microsoft Way), és amikor elsüllyednek a mocsárban, akkor még sikoltoznak is.

Avagy a probléma Apple-reinkarnációban: Nem Jól Használod(TM)

:D

( azbest | 2017. 07. 11., k – 11:26 )

Na igen, ez már ősidők óta így van. Anno a start menü és más ui elemek kapcsán is simán voltak elakadások úgy, hogy alig volt terhelés alatt a gép. Arra tippeltem, hogy az io műveletek blokkolják az ui kezelést...

Viszont a modern felületen megváltozott szerintem ez a viselkedés. Ott mindig szépen lemegy az animáció, ha kattintgatunk. Csak épp nem történik meg az esemény, amit ki kéne váltania. Vagy esetleg, ha nyitvahagyjuk és várunk eleget, akkor lehet, hogy percekkel később kez el önálló életet élni, amikor eszébe jut csinálni is valamit. Az pedig, hogy ez mennyire súlyosan jelentkezik frissítésről frissítésre változó.

( bennyh | 2017. 07. 11., k – 11:28 )

Mi az az említett Chrome build system? A Chrome főszála?
Használjon tűzrókát :).
Ki kellett volna próbálni 2016-al, hogy azon mennyire hal le az UI, valamint Linux alatt Chromiummal van-e ilyen gond.

( gee v | 2017. 07. 11., k – 15:38 )

Úgy olvastam, hogy "can't move my house".

Na, gondoltam, valami érdekes sztori lesz.

Aztán látom, hogy csak az egér akad. Pfff.

( Zsugabubus | 2017. 07. 11., k – 11:43 )

Ebben inkább az az érdekes, hogy a build közben ilyen fontos kernelfüggvények lassúak, mint az NTGdiCloseProcess. Mintha gcc közben az XCloseDisplay() (igaz, az nem kernel mód) lenne a szűk keresztmetszet.

A compiler/make/mittoménmi, ami a chromeot buildeli feltehetőleg Win32 Console Mode programok.
Mondjuk úgy tűnik, lehet használni a GDI rajzoló függvényeket konzolon is :)
https://www.daniweb.com/programming/software-development/threads/173412…

Simán kapsz egy window handlet-t a GetConsoleWindowra(). Szóval minden egyes folyamathoz, ami a build közben elindul van egy GDI ablak is!?

Bár azért továbbgondolva, nem hinném, hogy minden cmd.exe-ben indított kis program saját window handle-val rendelkezik. Lehet, hogy a build rendszer olyan, hogy mindent cmd.exe-vel indít :)

( Nyosigomboc v | 2017. 07. 11., k – 16:11 )

Ilyen gagyi vason hasznal Windowst?? Meg jo, hogy akad. Tegyen ra XP-t, azt talan elbirja. (vagy valtson jobb OS-re)

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

( trey | 2017. 07. 12., sze – 12:41 )

"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."

--
trey @ gépház