Przerwania

Zdaje sobie sprawe, ze do Marka Russinovicha to mi daleko, ale jezeli brac przyklad, to z najlepszych. Tak jak on spotykal swoje "case of the unexplained", tak i ja, i kazdy z nas obserwuje czasem naprawde dziwne zjawiska z pozornie dobrze znanym komputerem.

Jako Security Trusted Advisor, zostalem zaopatrzony w bardzo przyjemnego netbooka, (tak swoja droga wyobrazcie sobie konferencje, na której uczestnicy dostaja netbooki – prowadzacy sesje w sumie moze sie spakowac i wyjsc, i tak nikt go nie slucha, bo kazdy ma swoja zabawke) i po obejrzeniu wynalazków zainstalowanych przez producenta stwierdzilem, ze format i instalacja od nowa to jest to, czego mi trzeba. Pomijam juz to, ze na procesorze x64 zainstalowany byl system 32bit.

Instalacja systemu nie jest specjalnie ciekawym tematem zwlaszcza, ze przebiegla bez zadnych sensacji. Doinstalowalem swieze sterowniki do wszystkiego, co mi sie w oczy rzucilo i komputer byl gotowy do pracy.

Po jakims czasie, jeszcze w czasie instalacji niezbednych aplikacji, zaczalem odnosic wrazenie, ze komputer jakos wolno dziala, ale jako ze to netbook – duzo mu bylem w stanie wybaczyc. Szybki rzut oka na Task Manager pokazal, ze procesy nie zjadaja specjalnie duzo CPU, ale tryb jadra jednak cos tam sobie przetwarza. Tym bardziej zrzucilem w myslach wine na procesor ATOM i pracowalem dalej. W procesie przygotowania nowego komputera, przychodzi taki moment, ze instaluje sie Process Explorer. Moze nie wszyscy w domach go uzywaja, ale znam wiele osób, które nie wyobrazaja sobie bez niego komputera i ja sam jestem taka osoba. I Process Explorer pokazal moje problemy wydajnosciowe juz w troche innym swietle:

snip1

Po pierwsze, zajetosc procesora nie od razu byla taka duza i wzrastala z czasem (obrazek powstal po kilkudziesieciu godzinach pracy systemu), po drugie, to juz nie bylo tylko wrazenie spowolnienia pracy. System po prostu sie nie nadawal do uzytku. Oczywiscie restart na jakis czas pomagal, ale to zadna przyjemnosc.

Wypadalo wiec dowiedziec sie, kto jest winny.

Dla pewnosci (choc widac bylo, ze przyczyna raczej nie tutaj lezy) sprawdzilem watki procesu System. Oczywiscie troche ich bylo, ale ich aktywnosc nie wykraczala poza zupelnie typowe zachowania.

snip2

Nadeszla wiec pora na znalezienie odpowiedzi na pytanie, który ze sterowników obsluguje przerwania w taki sposób, ze zjada mi prawie polowe mocy obliczeniowej. Dla przypomnienia dodam, ze w systemie Windows wyglada to tak:

  1. Sprzet zglasza przerwanie
  2. W trybie jadra wywolywana jest obsluga przerwania i Microsoft grzecznie prosi, zeby nie zajela wiecej niz 10µs.
  3. Jezeli obsluga przerwania "wie", ze pracy jest wiecej niz da sie wykonac w zalecanym czasie, moze odlozyc jej czesc na pózniej, pozostawiajac jej wykonanie mechanizmom DPC.

Jak widac na pierwszym obrazku, tutaj nic powaznego do DPC nie trafialo. Wszystkiemu winny byl sterownik obslugujacy przerwanie. Warto zwrócic uwage, ze zalecany czas obslugi to tylko zalecenie. Windows wychodzi z zalozenia, ze obsluga przerwan (tak jak masa innych rzeczy, które robia pracujace w trybie jadra sterowniki) jest swieta i skoro sterownik nie zastosowal sie do zalecenia dziesieciu mikrosekund, to wie lepiej i nie nalezy mu przerywac. Gorzej tylko, gdy posrednio Windows zaufa w ten sposób jakiemus mniej bieglemu programiscie...

Próbujac znalezc odpowiedz na postawione wyzej pytanie "który to sterownik?", staniemy przed dwoma faktami i jak zwykle jeden ucieszy a drugi troche mniej. Pozytywna informacja jest to, ze Windows ma mechanizmy ETL dzieki którym da sie wygodnie zajrzec do tego, co robi jadro. Mniej pozytywna – ze narzedzia, którymi mozna to zrobic nie sa wbudowane w system. Trzecia wiadomosc przynosi jednak pewna nadzieje, poniewaz wszystko to, co moze nam byc potrzebne jest wbudowane w bezplatnie dostepny pakiet WDK.

Tak wiec po zainstalowaniu WDK (co ciekawe instaluje sie on domyslnie folderze WinDDK na dysku C:\ zamiast w Program Files), mozna bylo przystapic do dzialania.

  • Krok pierwszy: podrecznikowe (opisane na przyklad w Windows Internals) polecenie tracelog –start –f c:\mojtrace.etl –dpcisr –UsePerfCounter –b 64 – uruchamia ono rejestrowanie w pliku zdarzen wygenerowanych przez jadro, w szczególnosci (dzieki zastosowaniu parametru –dpcisr) przez obsluge przerwan. Nalezy miec swiadomosc, ze tych zdarzen moze byc dosc duzo, wiec wynikowy plik moze przyrastac po kilka MB na sekunde. U mnie przez 20s nazbieralo sie prawie 1500000 zdarzen, wiec jako próbka do analizy powinno wystarczyc.
  • Krok drugi: zatrzymanie sledzenia poleceniem tracelog –stop
  • Krok trzeci: przerobienie pliku etl na cos bardziej sympatycznego. Polecenie tracerpt jest wbudowane w system i wpisane w postaci tracerpt c:\mojtrace.etl –report c:\raport.htm –f html wygeneruje naprawde przyjazny w lekturze plik zawierajacy podsumowanie i analize zebranych danych.

W moim przypadku, wynik byl jasny:

snip3

Iastor.sys Po kolejnym poleceniu driverquery | findstr / iastor latwo mozna zobaczyc, ze winny jest "Intel AHCI Controller" czyli intelowskie sterowniki do kontrolera dysku twardego. U mnie w wersji 8.9.0.1023. Teoretycznie jest to ich najswiezsza wersja, ale na stronach producenta daje sie odnalezc równiez wersja 9.6. Po szybkiej aktualizacji i niezbednym w tym przypadku restarcie – wszystko wydaje sie dzialac bez zarzutu.

Autor: Grzegorz Tworek [MVP]