How to know linux scheduler time slice?

Question

I'm looking for the value of the time slice (or quantum) of my Linux kernel.

Specific Questions:

• 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 ?

Abscise

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

Hylomorphism

However it seems that rt.h appeared with Linux kernel 3.9. – Abscise

Before Linux kernel v3.9, the definition of RR_TIMESLICE was located in include/linux/sched.h. Before Linux kernel v3.4, the definition was named DEF_TIMESLICE and was located in kernel/sched/sched.h. – Hylomorphism

Note that this answer concerns only threads scheduled with the realtime priority RR – Rexrexana

Excuse me. Isn't 100 * 100 = 10000, and 10,000/1000 = 10? So how is that 100 msecs? – Profane

@Profane The comment default timeslice is 100 msecs may be referring to a kernel configured with CONFIG_HZ=1000; in this case (100 * (1000) / 1000) is equal to 100. – Hylomorphism

Interesting. But how are processes able to send new data to the monitor 60 times per second if each slice lasts up to 100ms? Surely the process needs to be asked for graphical output more frequently than this? – Marashio

@goblin When a process is available to be scheduled, the Linux scheduler will evaluate whether the current process should be preempted. For your hypothetical case of a process sending data to the monitor 60 times per second, it would likely preempt the other process since it's used a smaller proportion of the CPU so far; the CFS scheduler tries to schedule processes so that each has a proportional usage of CPU time based on their priority value. – Hylomorphism

@goblin If the process is SCHED_RR rather than SCHED_NORMAL, then yes you might have a problem if you have a process with a higher priority that is using up all 100ms without yielding. Most processes however will have periods where they wait for some sort of I/O or other blocking operation, so they will end up yielding the processor to lower priority tasks. – Hylomorphism

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

Hewet

Is this true for batch processes too? – Janeth

This is true to every process that run under CFS scheduler (not real-time process) – Hewet

@Janeth excellent point. The SCHED_BATCH timeslice is longer - 1.5 seconds. https://mcmap.net/q/77039/-what-is-difference-between-sched_batch-and-sched_other-scheduling – Monas

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

Corncrib

Answer 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!

Topeka

Mine matched up, maybe they fixed it... :) – Respectable

Answer 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

Rosa