Dlaczego wartości nikłości wynoszą od -20 do 19?


22

To nicepolecenie pozwala dostosować priorytet planowania („bezpieczeństwo”) programu. We wszystkich używanych przeze mnie systemach uniksowych niceness jest określona przez zakres liczb całkowitych, gdzie -20 jest najkorzystniejszym priorytetem planowania, 0 jest domyślnym, a 19 jest najmniej korzystnym.

Posiadanie 0 jako domyślnej wartości jest wystarczająco intuicyjne, ale dlaczego -20 i 19 zostały wybrane jako punkty końcowe zakresu? Dlaczego nie -128 i 127, które dokładnie pasowałyby do podpisanego bajtu 8-bitowego? Albo dlaczego nie -100 do 100, co jest bardziej intuicyjne dla ludzi o dziesiętnych umysłach, lub podobnie, ale nieco bardziej ergonomicznie, od -99 do 99? Czy zakres od -20 do 19 został wybrany arbitralnie, czy też ma jakiś związek z wewnętrznymi elementami harmonogramu, z którymi nicepierwotnie współpracował? (Rozumiem, że dzisiaj nie ma takiej relacji, przynajmniej w przypadku Linuksa, którego harmonogram używa priorytetów w zakresie od 0 do 139. Interesują mnie jednak historyczne przyczyny zakresu od -20 do 19).


4
Nie mogę znaleźć odniesienia wyjaśniającej, dlaczego wybrano ten konkretny zakres, ale zauważmy, że w V7 priorytet pasuje do podpisanego bajtu - patrz proc.h - a funkcja setpri ustawia priorytet na min(127, (recent CPU usage on a scale of 0 to 15) + 50 + pp->p_nice - 20), a priorytety <25 były zarezerwowane dla procesy wykonujące nieprzerwane rzeczy. Więc uprzejmość musiała być swego rodzaju ograniczonym zasięgiem.
Mark Plotnick

Odpowiedzi:


7

Wewnętrzne poziomy głośności wynoszą 0–39, ale przyrosty są dodatnie lub ujemne. Źródło . Odpowiedź brzmi więc, że liczby (dodatnie i ujemne) akceptowane przez to nicepolecenie prowadzą od 20, domyślnego poziomu, do dowolnego miejsca w zakresie 0–39.

Dlaczego więc 0-39? Konkretny zakres był tym, co działało w pierwotnej implementacji projektantów. Powodem, dla którego bardziej pozytywne wartości są ładniejsze, jest to, że miły poziom jest dodawany do ostatniego użycia procesora w procesie określania priorytetu. Aby zapewnić przybliżone szeregowanie w trybie round-robin, jądro śledzi, ile procesora ostatnio spalił każdy proces i przełącza się na procesy, które nie miały tak dużo. Im wyższy przyjemny poziom, tym więcej czasu procesorowi wydaje się mieć proces i tym częściej program planujący uśpi ten proces lub go uśpi. Patrz : Projektowanie systemu operacyjnego UNIX , Maurice J. Bach, Prentice-Hall 1986, sec. 8.1 (8.1.4 dla specyficzności). ISBN 0-13-201799-7.


1
Mylisz się, zakładając, że program planujący uśpi proces, jeśli ma on złą, ładną wartość. Zamiast tego program planujący nie obudzi procesu uśpienia, jeśli istnieją inne procesy gotowe do uruchomienia, a procesy te mają lepszy poziom. Zauważ, że proces jest uśpiony, gdy wywołuje syscall, który wymusza uśpienie zasobów lub gdy proces zużywa kwant procesora, a na procesor czekają inne uprzywilejowane procesy.
schily

-4

Mylisz się: jeśli korzystasz z systemu UNIX, w którym interfejs nice () ma sens, NZEROto domyślna wartość nice i NZERO is 20.

Żeby było bardziej oczywiste: zapytałeś o polecenie nicei jednocześnie wspominałeś o poziomach bezwzględnych, ale ładne polecenie nie zarządza wartościami bezwzględnymi, ale raczej przyrostami w stosunku do bieżącego poziomu. W przypadku stanu domyślnego niezły poziom NZEROto 20.

Ładne wartości to 0..2 * NZERO-1 lub 0..39

Zauważ, że chociaż domyślny program planujący UNIX może nadal być w stanie zrobić coś użytecznego z niezłą wartością, nie ma znaczenia, jeśli używasz specjalistycznego programu planującego, np. Programu planującego w czasie rzeczywistym.


2
Wygląda na to, że mylisz interfejs powłoki i interfejs C. To pytanie dotyczy nicepolecenia powłoki.
Gilles „SO- przestań być zły”

Cóż, to wy mylicie rzeczy. Ładne polecenie wie tylko o delcie, ale pytanie wymienia ładne wartości. Pytanie dotyczyło dobrych wartości i odpowiedziałem na to.
schily
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.