53

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 ?

5 Answers 5

49

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.

8
  • However it seems that rt.h appeared with Linux kernel 3.9.
    – backlash
    May 6, 2013 at 20:39
  • 8
    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. May 6, 2013 at 20:45
  • 4
    Note that this answer concerns only threads scheduled with the realtime priority RR Aug 7, 2014 at 13:11
  • 1
    Excuse me. Isn't 100 * 100 = 10000, and 10,000/1000 = 10? So how is that 100 msecs?
    – Abundance
    May 5, 2015 at 2:57
  • 4
    @Abundance 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. May 5, 2015 at 18:02
44

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.

3
  • 1
    Is this true for batch processes too?
    – user239558
    Apr 9, 2014 at 9:11
  • 2
    This is true to every process that run under CFS scheduler (not real-time process) Apr 11, 2014 at 23:29
  • 4
    @user239558 excellent point. The SCHED_BATCH timeslice is longer - 1.5 seconds. stackoverflow.com/a/31286586/799204
    – sourcejedi
    Sep 2, 2018 at 13:40
12

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.

11

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!

1
  • 1
    Mine matched up, maybe they fixed it... :)
    – rogerdpack
    Nov 16, 2019 at 3:54
6

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
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.