How to know linux scheduler time slice?

Question 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.

This is because the Completely Fair Scheduler, the default Linux scheduler, assigns a proportion of the processor to a process rather than a fixed timeslice. That means the timeslice for each process is proportional to the current load and weighted by the process' priority value.

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.

Question 2

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

Question 3

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.

Question 4

I attemped to google this question's same doubt of time slice of SCHED_RR in Linux, but I did not get clear answer both from here and the kernel's source code.

After further checking, 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've configured.

Same as the value of /proc/sys/kernel/sched_rr_timeslice_ms, which input value is in milliseconds, but it stores and outputs in jiffies!

So, when your CONFIG_HZ=100 is set, you'll find that:

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

It's little bit confused, hope this can help you to understand it!

Question 5

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.