gotar pisze:
> Tak. Wtedy wszystko ląduje na jednym rdzeniu, który ma 100%, a pozostałe
> nie są w ogóle używane i świecą zerami.
To koszmar. Nie jestem specjalistą w kwestii jądra Linuksa,
ale wydawało mi się, że inaczej to wygląda.
W Windows sytuacja wygląda następująco:
1. Urządzenie zgłasza przerwanie. Wywoływana jest procedura
obsługi przerwania (ISR) w trybie nadzorowanym, w sposób
naturalny dla procesora.
2. ISR ma za zadanie jedynie potwierdzić odebranie przerwania,
zidentyfikować źródło i wywołać procedurę obsługi przer-
wania konkretnego sterownika urządzenia.
3. Ta z kolei jedynie informuje urządzenie o obsłużeniu
przerwania, programuje je w taki sposób, aby nie nadpisało
danych (jeżeli trzyma je w jakichś swoich buforach) i
zgłasza potrzebę wykonania asynchronicznej procedury
kontynuującej przetwarzanie.
4. Na tym ISR się kończy. System wraca na niski poziom IRQL
i poziom użytkownika. Całość trwała drobną chwileczkę
w porównaniu do całości czasu potrzebnego na obsłużenie
przerwania.
5. Jeżeli kolejka procedur asynchronicznych jest niepusta,
jest opróżniana. W tym momencie - w kwancie czasu procesu
użytkownika (ale na podwyższonym IRQL i w trybie jądra),
na dowolnym wolnym procesorze - kończona jest obsługa
przerwania, dane kopiowane z urządzenia do pamięci lub
vice versa i w ogóle robione jest wszystko, co wymaga
jeszcze pracy w trybie jądra i kontaktu z urządzeniem.
> Nie wiem jak miał NT, ale przejmowanie obsługi przerwania na zmianę
> przez procesory było zaimplementowane sprzętowo bodajże w PIII. Od tego
> czasu jest to po prostu gorzej zrobione na poziomie hardware.
Ale tu nie chodzi o samo zgłaszanie przerwań. Tu chodzi o
implementację obsługi przerwań. W gorszym rozwiązaniu będzie
się je obsługiwało na procesorze, który odebrał przerwanie.
W lepszym -- na dowolnym wolnym procesorze, angażując ten
odbierający ino na krótki moment.
-- |""""""""""""""""""""""""""""""""""""""""""""""""""""""""""| | Radosław Sokół | http://www.grush.one.pl/ | | | Administrator, Politechnika Śląska | \................... Microsoft MVP ......................../Received on Sun Apr 13 19:30:25 2008
To archiwum zostało wygenerowane przez hypermail 2.1.8 : Sun 13 Apr 2008 - 20:51:58 MET DST