How to know linux scheduler time slice?


How to know linux scheduler time slice?

I’m looking for the value of the time slice (or quantum) of my Linux kernel.
Is there a /proc file which expose such an information ?
(Or) Is it well-defined in the Linux header of my distributions ?
(Or) Is there a C function of the Linux API (maybe sysinfo) that expose this value ?
Thanks in advance.


Solution 1:

The quantum allocated for a particular process may vary:

You can tune “slice” by adjusting sched_latency_ns and
sched_min_granularity_ns, but note that “slice” is not a fixed
quantum. Also note that CFS preemption decisions are based upon
instantaneous state. A task may have received a full (variable)
“slice” of CPU time, but preemption will be triggered only if a more
deserving task is available, so a “slice” is not the “max
uninterrupted CPU time” that you may expect it to be.. but it is
somewhat similar.

For special-purpose realtime processes which use SCHED_RR, the default timeslice is defined in the Linux kernel as RR_TIMESLICE in 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)

You can use sched_rr_get_interval() to get the SCHED_RR interval for a specific SCHED_RR process.

Solution 2:

CFS (which is default scheduler for processes) has no fixed timeslice, it is calculated at runtime depending of targeted latency (sysctl_sched_latency) and number of running processes. Timeslice could never be less than minimum granularity (sysctl_sched_min_granularity).

Timeslice will be always between sysctl_sched_min_granularity and sysctl_sched_latency, which are defaults to 0.75 ms and 6 ms respectively and defined in kernel/sched/fair.c.

But actual timeslice isn’t exported to user-space.

Solution 3:

There is some confusion in the accepted answer between SCHED_OTHER processes (i.e., those operating under the (default) non-realtime round-robin timesharing policy) and SCHED_RR processes.

The sched_latency_ns and sched_min_granularity_ns files (which are intended for debugging purposes, and visible only if the kernel is configured with CONFIG_SCHED_DEBUG) affect the scheduling of SCHED_OTHER processes. As noted in Alexey Shmalko’s answer, the time slice under CFS is not fixed (and not exported to user space), and will depend on kernel parameters and factors such as the process’s nice value.

sched_rr_get_interval() returns a fixed value which is the quantum that a SCHED_RR process is guaranteed to get, unless it is preempted or blocks. On traditional Linux, the SCHED_RR quantum is 0.1 seconds. Since Linux 3.9, the limit is adjustable via the /proc/sys/kernel/sched_rr_timeslice_ms file, where the quantum is expressed as a millisecond value whose default is 100.

Solution 4:

I googled this tickets about same doubt of time slice of SCHED_RR in Linux.
But I cannot get clear answer both from here and kernel source code.
After further check, I found the key point is “RR_TIMESLICE” is the default time slice in jiffies, not millisecond! So, the default time slice of SCHED_RR is always 100ms, no matter what HZ you configured.

Same as the value of “/proc/sys/kernel/sched_rr_timeslice_ms”, which input value in millisecond, but it store and output in jiffies! So, when your CONFIG_HZ=100, you will find that:

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

It’s little bit confused.
Hope this can help you to understand it!

Solution 5:

sysctl is used to read and write kernel parameters at runtime. The parameters available are those listed under /proc/sys/ . Also Linux 3.9 added a new mechanism for adjusting (and viewing) the SCHED_RR quantum: the /proc/sys/kernel/sched_rr_timeslice_ms file exposes the quantum as a millisecond value, whose default is 100. Writing 0 to this file resets the quantum to the default value. So you might want to try:

sysctl kernel.sched_rr_timeslice_ms