Jak poznać fragment czasowy programu linux scheduler?

Question

Szukam wartości fragmentu czasowego (lub kwantowego) mojego jądra Linux.

Czy istnieje plik /proc, który udostępnia takie informacje?

(Czy też) Czy jest dobrze zdefiniowany w nagłówku Linuxa moich dystrybucji?

(Czy jest) funkcja języka C interfejsu API systemu Linux (może sysinfo), która ujawnia tę wartość?

Z góry dziękuję.

Answer 1

Domyślny czas Linuksa dla procesów w czasie rzeczywistym zdefiniowany jest w jądrze Linux jako RR_TIMESLICE w include/linux/sched/rt.h.

/* 
* default timeslice is 100 msecs (used only for SCHED_RR tasks). 
* Timeslices get refilled after they expire. 
*/ 
#define RR_TIMESLICE   (100 * HZ/1000) 

Należy pamiętać, że faktyczna kwantowa przydzielone do konkretnego procesu may be different od tej wartości:

Można dostroić „plaster”, dostosowując sched_latency_ns i sched_min_granularity_ns, ale należy pamiętać, że „kawałek "nie jest ustalonym kwantem . Należy również zauważyć, że decyzje dotyczące decyzji CFS opierają się na natychmiastowym stanie. Zadanie mogło otrzymać pełny (zmienny) "kawałek" czasu procesora, ale wywarcie będzie uruchamiane tylko wtedy, gdy jest dostępne więcej zasługującego na więcej zadania , więc "plaster" nie jest "maks. nieprzerwanym czasem procesora", który może się spodziewać, że to będzie ... ale jest to trochę podobne.

Można jednak użyć sched_rr_get_interval(), aby uzyskać przedział SCHED_RR dla danego procesu w czasie rzeczywistym.

Answer 2

CFS (który jest domyślnym harmonogramem dla procesów) nie ma ustalonego timelice, jest obliczany w czasie wykonywania w zależności od docelowego opóźnienia (sysctl_sched_latency) i liczby uruchomionych procesów. Timeslice nigdy nie może być mniejsza niż minimalna ziarnistość (sysctl_sched_min_granularity).

Timeslice będą zawsze między sysctl_sched_min_granularity i sysctl_sched_latency, które domyślnie wynoszą odpowiednio 0,75 ms i 6 ms i są zdefiniowane w kernel/sched/fair.c.

Ale rzeczywisty timeslice nie jest eksportowany do przestrzeni użytkownika.

Answer 3

Istnieje pewne zamieszanie w przyjętym odpowiedź między SCHED_OTHER procesów (czyli działających pod (domyślnie) non-realtime round-robin polityki timesharing) i SCHED_RR procesów.

W sched_latency_ns i sched_min_granularity_ns plików (które są przeznaczone do celów diagnostycznych i widoczne tylko gdy jądro jest skonfigurowany CONFIG_SCHED_DEBUG) wpływać na szeregowanie SCHED_OTHER procesów. Jak zauważono w odpowiedzi Alexeya Shmalko, wycinek czasu w CFS nie jest ustalony (i nie jest eksportowany do przestrzeni użytkownika) i zależy od parametrów jądra i czynników, takich jak dobra wartość procesu.

sched_rr_get_interval() zwraca stałą wartość, która jest kwantem, do którego zagwarantowany jest proces SCHED_RR, chyba że jest uprzednio wyzerowany lub blokuje. W tradycyjnym systemie Linux kwantjest równy 0,1 sekundy.Ponieważ Linux 3.9, limit wynosi adjustable poprzez plik /proc/sys/kernel/sched_rr_timeslice_ms, gdzie kwantowa jest wyrażona jako wartość milisekundy, którego domyślna to 100.

Answer 4

google to bilety o tym samym wątpliwości wycinka czasu SCHED_RR w Linuksie. Ale nie mogę uzyskać jednoznacznej odpowiedzi zarówno tutaj, jak i kodu źródłowego jądra. Po dalszym sprawdzeniu, znalazłem kluczowy punkt "RR_TIMESLICE" to domyślny fragment czasu w jiffies, a nie milisekundach! Domyślny przedział czasowy SCHED_RR wynosi zawsze 100ms, bez względu na skonfigurowane HZ.

sama jak wartość "/ proc/sys/kernel/sched_rr_timeslice_ms", która wartość wejściowa w milisekundy, ale przechowywanie i wyjście w jiffies! Tak więc, gdy CONFIG_HZ = 100, okaże się, że:

# echo 100 > /proc/sys/kernel/sched_rr_timeslice_ms 
# cat /proc/sys/kernel/sched_rr_timeslice_ms 
10 

To trochę zagmatwane. Mam nadzieję, że to pomoże ci to zrozumieć!