Planety czasowe w harmonogramie Round Robin

Question

Jeśli masz bardzo duży (powiedzmy zbyt duży) przedział czasowy dla programu planującego rundy czasowe, jaki efekt wydajności powinien być oczekiwany w systemie operacyjnym?

Myślałem tylko, że procesy wymagające dużo czasu przyniosłyby korzyści, ale większość procesów wykorzystuje niewielką ilość czasu, więc spowodowałoby opóźnienie w ukończeniu wszystkich mniejszych procesów?

przykład: kwant czasu 50 oraz procesów P1 = 400, P2 = 10, P3 = 150, P4 = 20, P5 = 10, P6 = 10

to my najbardziej prawdopodobne ja zastanawiać, czy jest wszystko, co moglibyście podzielić, o ile przedział czasowy jest zbyt mały lub zbyt duży.

Answer 1

Problem z round robinem polega na tym, że zadania nie są równe.

Dla zadań związanych z CPU; jeśli masz niezwykle ważne zadanie i tysiące nieistotnych zadań, wszystkie te nieważne zadania spowalniają wykonywanie ważnego zadania. W tym przypadku nie ma znaczenia, jak duże są odcinki czasu.

Dla zadań związanych z IO, round robin powoduje złe opóźnienie. Jeśli ważne zadanie odblokuje się (np. Przebudzi się po wywołaniu "uśpienia()", odbiera plik IO, na który czekało, itp.) To może poczekać, aż tysiące nieistotnych zadań przejdzie przez ich wycinki czasu przed ważnym zadaniem ma szansę zrobić cokolwiek. Zmniejszenie długości fragmentu czasu skróci czas, zanim ważne zadanie zacznie robić coś pożytecznego, ale także zmniejszy czas, w którym ważne zadanie zostanie wykonane, aby zrobić coś pożytecznego.

Uwaga: Możesz pokusić się o "naprawienie" tego przez odblokowywanie zadań, które przechodzą na czoło listy. W takim przypadku ważne zadanie może zostać wygłodzone na zawsze tylko dlatego, że nieistotne zadania nadal śpią i budzą się.

Zasadniczo, round-robin jest parującym stosem "bezużytecznym" i nie ma znaczenia, co robisz, dopóki nie zastąpisz go zupełnie innym algorytmem planowania, który ma przynajmniej pewien szacunek dla ważności/priorytetu różnych zadań .

Dla uproszczonego przykładu; możesz mieć 3 różne priorytety zadań, w których system operacyjny zawsze wykonuje zadania o najwyższym priorytecie (w tym upewnia się, że zadania o wyższym priorytecie natychmiastowo wykonują zadania o niższym priorytecie) i round-robin jest używany do zadań o tym samym priorytecie. W takim przypadku możesz mieć różne długości odcinków czasu dla różnych priorytetów (np. Zadania o wysokim priorytecie otrzymują tylko 1 ms, zadania o średnim priorytecie dostają 10 ms, zadania o niskim priorytecie osiągają 125 ms).

Dla przykładu "mniej uproszczonego"; możesz mieć kilka całkowicie różnych zasad planowania (np. jeden dla zadań w czasie rzeczywistym, jeden dla normalnych zadań, jeden dla zadań w tle/bezczynności), które wszystkie używają różnych podejść (np. najwcześniejszy termin jako pierwszy, zmienny przedział czasowy, itp.); gdzie istnieje 256 priorytetów zadań dla każdej polityki harmonogramu.

Answer 2

Z punktu widzenia przekrojów czasowych istnieją 2 skrajne scenariusze, które zmniejszają wydajność. Jeśli przedział czasowy to:

1. Zbyt duża: powoduje, że małe procesy czekają bardzo długo, gdy mogły zakończyć się znacznie wcześniej, gdyby fragment czasowy był mniejszy. Ponadto nie jest to korzystne dla procesów interaktywnych, które wymagają mniejszego, ale częstego czasu procesora.
2. Zbyt mały: powoduje częste przełączanie kontekstu, co oznacza znaczny narzut.

Historycznie, programiści OS ciężko pracowali, aby znaleźć równowagę pomiędzy tymi dwoma skrajnościami i istnieją różne algorytmy oparte na priorytetach, które zostają wchłonięte przez Round-robin dla lepszej wydajności.