Im więcej rdzeni tym gorzej: Windows 10 zacina się przy poważnej pracy

Bruce Dawson, autor bloga Random ASCII, używa niezłegokomputera. 24 rdzenie, 48 wątków, 64 GB RAM, szybki dysk SSD. Możnaby się było spodziewać, że nawet poważna praca na takiejmaszynie, np. kompilowanie przeglądarki Chrome, będzie przebiegaćbłyskawicznie. Tymczasem gdy rozpoczynała się kompilacja, systemzamierał, Dawsonowi przycinał się nawet wskaźnik myszy. I towcale nie dlatego, że zabrakło rdzeni. Zawinił Windows 10.

Gdyby jeszcze rdzenie były obciążone w 100%, problem byłbyzrozumiały. Sęk w tym, że analiza obciążeń za pomocą traceraETW pokazała, że obciążenie pojedynczego rdzenia rzadko kiedyprzekraczało 50%. Musiało chodzić o coś innego – problem tkwiłw samym systemie.

Przyglądając się zachowaniu procesów, szybko tworzonych iniszczonych w takich związanych z kompilacją obciążeniachroboczych, programista zauważył, że znaczna ich część zostajezablokowana na 200 mikrosekund przez funkcję NtGdiCloseProcess,należącą do zintegrowanego z kernelem podsystemu GDI (GraphicsDevice Interface).

W testowanym okresie zamrożenia interfejsu użytkownika na 1,125sekundy, okres oczekiwania dla wszystkich wątków wyniósł łącznieponad 63 sekundy. Z tego okresu 1,125 sekund 95% czasu spędzane byłowewnątrz NtGdiCloseProcess – najwyraźniej wąskim gardleWindowsa.

Stąd też całe wyczekiwanie systemu, gdy tysiące procesówzamykanych procesów walczyły o jedną blokadę w NtGdiCloseProcess,zamrażając aktywność interfejsu użytkownika, a im dłużejkomputer pracował, tym sytuacja była gorsza – jak pokazujeDawson, po restarcie problem nie był tak dotkliwy.

Programista przygotował więc testowy program, który tworzyłtak szybko jak możliwe tysiące procesów, czekał pół sekundy, anastępnie nakazywał wszystkich tych procesów jednoczesnezamknięcie. Program ten został uruchomiony na słabszychkomputerach – czterordzeniowym, ośmiowątkowym laptopie zWindowsem 10, oraz starym dwurdzeniowym komputerze z Windows 7.Porównanie pokazało coś zaskakującego: na tej starej maszynietworzenie procesów było oczywiście znacznie powolniejsze, ale ichniszczenie było tak szybkie, jak tylko możliwe, odbywało się wpełni równolegle.

Gdzieś między Windowsem 7 a Windowsem 10 doszło więc w tymsystemie do regresji, w wyniku której NtGdiCloseProcess stało sięwąskim gardłem, tym węższym, im potężniejsza jest maszyna. Jakbowiem podkreśla Dawson, środowisko kompilacji Chrome uruchamia tymwięcej procesów, im więcej mamy rdzeni, a to oznacza więcejprocesów rywalizujących o tę funkcję.

Odkrycie trafiło do Microsoftu, który zapowiedział, że zbadaproblem. Póki co, mamy do czynienia z podręcznikowym wręczprzykładem prawa Amdahla, które mówi, że im więcej rdzenistosowanych jest do wykonania programu, w tym większym stopniu naczas wykonania wpływają te fragmenty kodu, których nie możnawykonać równolegle. Dawson pisze: to nie jest po prostu „mam24-rdzeniowe CPU i nie mogę ruszyć myszą”, ale „mam24-rdzeniowe CPU i dlatego nie mogę ruszyć myszą”.

Szczegóły analizy i linki do wykorzystanych narzędziznajdziecie na blogu RandomASCII.