Istnieją dwa przypadki, w których kod scheduler schedule() jest invoked-W jakim kontekście działa kod programu planującego?
Gdy proces dobrowolnie wzywa schedule()
czasowy przerwania połączenia schedule()
W przypadku 2, myślę schedule() działa w kontekście przerwań, ale co z pierwszym przypadkiem? Czy działa w kontekście procesu, który go wywołał?
Czy są jeszcze jakieś scenariusze, które wywołują schedule()?
schedule() zawsze działa w kontekście procesu. W drugim przypadku, gdy jest on inicjowany przez przerwanie zegara, znajduje się on na ścieżce powrotnej od jądra do przerwanego procesu, w którym wywoływana jest nazwa schedule().
Cóż, harmonogram() występuje jako wywołanie systemowe, które jest po prostu przerwaniem pułapki AFAIK, prawda? –
@Jesus Ramos: "kontekst procesu" i "kontekst przerwań" to terminy rozwojowe jądra systemu Linux, które opisują kontekst kodu wykonywany w przestrzeni jądra: czy można go uznać za wykonywanie w imieniu określonego procesu (jak w systemie call) lub alternatywnie obsługujące przerwanie sprzętowe. – caf
Tak, wiem, że terminologia polega na tym, że było to trochę zagmatwane w tym sensie, ponieważ wywołanie systemowe jest technicznie przerwaniem, więc nie jestem pewien, czy to właśnie miał na myśli, ani sposób, w jaki wywołanie jest wykonywane. –
Gdy proces wywołuje schedule(), uruchamia się w kontekście wywołania systemowego, który jest oparty na przerwaniach. W drugim przypadku przerwanie sprzętowe wyzwala wywołanie schedule(). W obu przypadkach działa jako przerwanie. AFAIK to jedyne czasy, w których wywoływana jest nazwa schedule(), ponieważ większość manipulacji harmonogramem obejmuje modyfikowanie kolejki uruchamiania jądra obiektów do zaplanowania, chociaż proces może zostać przerwany, ale zwykle odbywa się to za pomocą przerwania, aby powiedzieć procesowi o wydajności lub procesie samo.
__schedule() jest główną funkcją harmonogramu.
głównych sposobów prowadzenia harmonogramu, a tym samym wprowadzenie tej funkcji są:
Explicit blokowanie: mutex, semafor, waitqueue itp
TIF_NEED_RESCHED flaga jest sprawdzana na przerwanie i powrót w przestrzeni użytkownika ścieżki. Na przykład zobacz arch/x86/entry_64.S. Aby sterować prewencją między zadaniami, program planujący ustawia flagę w module obsługi przerwań timera scheduler_tick().
Pobudki tak naprawdę nie powodują wejścia w harmonogram(). Dodają zadanie do kolejki uruchamiania i to wszystko. Teraz, gdy nowe zadanie dodany do run-kolejce ma pierwszeństwo bieżącego zadania, a następnie ustawia budzeniem TIF_NEED_RESCHED i harmonogram() jest wywoływana na najbliższej możliwej okazji:
http://lxr.free-electrons.com/source/kernel/sched/core.c#L2389
jeszcze inny przypadek, w którym plan() zostanie wywołana, gdy bloki przetwarzania (na przykład w wyniku operacji I/O). – omer
@omer Jest przerwą czasową, która wywołuje harmonogram połączeń(), gdy bloki procesowe. więc twój przypadek jest taki sam jak w przypadku 2 – baotiao