Я ищу значение временного фрагмента (или кванта) моего ядра Linux.
Есть ли файл /proc, который предоставляет такую информацию?
(Или) Является ли он корректным в заголовке Linux моих дистрибутивов?
(Или) Есть ли функция C API Linux (возможно, sysinfo), которая раскрывает это значение?
Спасибо заранее.
Квант, выделенный для конкретного процесса, может варьироваться:
Вы можете настроить "срез", отредактировав sched_latency_ns и sched_min_granularity_ns, но обратите внимание, что "срез" не является фиксированным квантом. Также обратите внимание, что решения о преимущественном использовании CFS основаны на мгновенном состоянии. Задача могла получить полный (переменный) "срез" времени процессора, но преемственность будет срабатывать только в том случае, если доступна более достойная задача, поэтому "срез" не является "максимальным непрерывным временем процессора", что вы можете ожидать быть.. но это несколько похоже.
Для целевых процессов реального времени, в которых используется SCHED_RR, по умолчанию в ядре Linux определяется значение времени по умолчанию как RR_TIMESLICE в 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)
Вы можете использовать sched_rr_get_interval() для получения интервала SCHED_RR для определенного процесса SCHED_RR.
CFS (который является планировщиком по умолчанию для процессов) не имеет фиксированного таймлиса, он вычисляется во время выполнения в зависимости от целевой задержки (sysctl_sched_latency) и количества запущенных процессов. Временная шкала никогда не может быть меньше минимальной детализации (sysctl_sched_min_granularity).
Временная шкала всегда будет находиться между sysctl_sched_min_granularity и sysctl_sched_latency, которые по умолчанию равны 0,75 мс и 6 мс соответственно и определены в kernel/sched/fair.c.
Но фактический тайм-лист не экспортируется в пользовательское пространство.
В принятом ответе между процессами SCHED_OTHER есть некоторая путаница (т.е. те, которые работают в соответствии с (по умолчанию) политикой с временным разделением времени без реального времени) и SCHED_RR.
Файлы sched_latency_ns и sched_min_granularity_ns (предназначенные для целей отладки и видимые только в том случае, если ядро настроено с помощью CONFIG_SCHED_DEBUG) влияют на планирование процессов SCHED_OTHER. Как отмечалось в ответе Алексея Шмалько, временной срез под CFS не фиксирован (и не экспортируется в пространство пользователя), и будет зависеть от параметров и факторов ядра, таких как хорошее значение процесса.
sched_rr_get_interval() возвращает фиксированное значение, которое является квантом, гарантированным процессом SCHED_RR, если только он не вытеснен или не блокируется, В традиционном Linux квант SCHED_RR составляет 0,1 секунды. Начиная с Linux 3.9, ограничение настраивается через файл /proc/sys/kernel/sched_rr_timeslice_ms, где квант выражается как миллисекунда, значение по умолчанию 100.
Я просмотрел эти билеты по одному и тому же сомнению временного фрагмента SCHED_RR в Linux. Но я не могу получить ясный ответ как отсюда, так и от исходного кода ядра. После дополнительной проверки я обнаружил, что ключевой момент - "RR_TIMESLICE" - это срез времени по умолчанию в jiffies, а не миллисекунда! Таким образом, временной срез по умолчанию для SCHED_RR всегда равен 100 мс, независимо от того, какой HZ вы сконфигурировали.
То же самое, что и значение "/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
Это немного запуталось. Надеюсь, это поможет вам понять это!