Как узнать планировщик Linux time slice?

Я ищу значение временного среза (или кванта) моего ядра Linux.

здесь /proc файл, который предоставляет такую информацию ?

(или) это хорошо определено в заголовке Linux моих дистрибутивов ?

(или) есть ли функция C API Linux (возможно, sysinfo), которая предоставляет это значение ?

спасибо заранее.

31
c embedded-linux linux linux-kernel procfs

4 ответов

Квант, выделенный для определенного процесса могут различаться:

вы можете настроить "slice", регулируя sched_latency_ns и sched_min_granularity_ns, но обратите внимание, что "slice" не является фиксированным квантовый. Также обратите внимание, что решения CFS preemption основаны на мгновенное состояние. Задача может получить полную (переменную) "срез" времени процессора, но упреждение будет срабатывать только в том случае, если больше достойные задачи доступно, поэтому "slice" не является " max непрерывное время процессора", которое вы можете ожидать.. но это что-то похожее.

для специальных процессов реального времени, использующих SCHED_RR, timeslice по умолчанию определяется в ядре Linux как RR_TIMESLICE на включить / 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)

можно использовать sched_rr_get_interval() чтобы получить интервал SCHED_RR для определенного процесса SCHED_RR.

26

CFS (который является планировщиком по умолчанию для процессов) не имеет фиксированного timeslice, он рассчитывается во время выполнения в зависимости от целевой задержки (sysctl_sched_latency) и количество запущенных процессов. Интервал не может быть меньше минимальной зернистости (sysctl_sched_min_granularity).

Timeslice всегда будет между sysctl_sched_min_granularity и sysctl_sched_latency, которые по умолчанию равны 0,75 МС и 6 мс соответственно и определены в kernel / sched / fair.c.

но фактический timeslice не экспортируется в пространство пользователя.

23

существует некоторая путаница в принятом ответе между SCHED_OTHER процессы (т. е. те, которые работают под (По умолчанию) не в режиме реального времени круговой политики) и SCHED_RR процессы.

на sched_latency_ns и sched_min_granularity_ns файлы (которые предназначены для отладки и видны только в том случае, если ядро настроено на CONFIG_SCHED_DEBUG) влияет на планирование SCHED_OTHER процессы. Как отмечается в ответе Алексея Шмалько, временной срез под CFS не фиксирован (и не экспортируется пользователю space), и будет зависеть от параметров ядра и таких факторов, как хорошее значение процесса.

sched_rr_get_interval () возвращает фиксированное значение, которое является квантовым, что SCHED_RR процесс гарантированно получит, если он не будет предварительно или блоков. В традиционном Linux SCHED_RR квантовая 0,1 секунды. Начиная с Linux 3.9, ограничение регулируемый через /proc/sys/kernel/sched_rr_timeslice_ms file, где Квант выражается как значение миллисекунды, значение по умолчанию 100.

8

я гуглил эти билеты о том же сомнении во временном срезе SCHED_RR в Linux. Но я не могу получить четкий ответ как отсюда, так и из исходного кода ядра. После дополнительной проверки я нашел ключевой момент- "RR_TIMESLICE" - это временной срез по умолчанию в jiffies, а не миллисекунды! Итак, фрагмент по умолчанию время SCHED_RR всегда 100мс, неважно, что Гц настроен.

то же самое, что и значение "/proc/sys/kernel/sched_rr_timeslice_ms", входящее в МС, но он хранит и выводит в jiffies! Итак, когда ваш CONFIG_HZ=100, вы найдете, что:

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

Это немного смущает. Надеюсь, это поможет вам понять это!

2