1

While studying the kernel behaviour from RHEL6 to RHEL7, we came across an explanation on RHEL6 kernel parameters:

> kernel.sched_min_granularity_ns

sched_min_granularity_ns is the initial value for the scheduler period. The scheduler period is a period of time during which all runnable tasks should be allowed to run at least once. While CFS has no concept of time slices, you can think of the period as the initial chunk of time which is then divided evenly into timeslices, one for each runnable process. Note that this tunable only specifies the initial value. When too many tasks become runnable the scheduler will increase the period to avoid shortening run times too much.

/usr/share/doc/kernel-doc-2.6.32/Documentation/scheduler/sched-design-CFS.txt

>kernel.sched_latency_ns

It configures targeted preemption latency for CPU bound tasks.

The description regarding the kernel.sched_min_granularity_ns parameter confused us. Our understanding of the parameter is that it is the minimum amount of time for which each runnable task would run on the CPU (i.e. time-slice provided to each runnable task). For kernel.sched_latency_ns, it is the period during which all runnable task(s) would run at least once.

We derive our understanding from many other articles, such as this one and that one. Some links might refer to a different kernel version, but the general description of the parameter shouldn't become reversed.

1

Agreed. The RHEL6 doc is not consistent with the document it cites. Ignore it.

https://elixir.bootlin.com/linux/v2.6.32/source/Documentation/scheduler/sched-design-CFS.txt#L95

Thus the CFS scheduler has no notion of "timeslices" in the way the previous scheduler had, and has no heuristics whatsoever. There is only one central tunable (you have to switch on CONFIG_SCHED_DEBUG):

/proc/sys/kernel/sched_min_granularity_ns

which can be used to tune the scheduler from "desktop" (i.e., low latencies) to "server" (i.e., good batching) workloads. It defaults to a setting suitable for desktop workloads.

The default value of this in the same version was 1ms, which makes sense as minimum for a timeslice (corresponding to old-style CONFIG_HZ=1000).

https://elixir.bootlin.com/linux/v2.6.32/source/kernel/sched_fair.c#L40

1ms is several times too small for a plausible default for "a period of time during which all runnable tasks should be allowed to run at least once".

/*
 * Targeted preemption latency for CPU-bound tasks:
 * (default: 5ms * (1 + ilog(ncpus)), units: nanoseconds)
 *
 * NOTE: this latency value is not the same as the concept of
 * 'timeslice length' - timeslices in CFS are of variable length
 * and have no persistent notion like in traditional, time-slice
 * based scheduling concepts.
 *
 * (to see the precise effective timeslice length of your workload,
 *  run vmstat and monitor the context-switches (cs) field)
 */
unsigned int sysctl_sched_latency = 5000000ULL;

/*
 * Minimal preemption granularity for CPU-bound tasks:
 * (default: 1 msec * (1 + ilog(ncpus)), units: nanoseconds)
 */
unsigned int sysctl_sched_min_granularity = 1000000ULL;
0

The document that you linked to contains these definitions:

  • kernel.sched_latency_ns
    sched_latency_ns is the initial value for the scheduler period.  The scheduler period is a period of time during which all runnable tasks should be allowed to run at least once.  While CFS has no concept of time slices, you can think of the period as the initial chunk of time which is then divided evenly into timeslices, one for each runnable process.  Note that this tunable only specifies the initial value.  When too many tasks become runnable the scheduler will use kernel.sched_min_granularity_ns instead.
    /usr/share/doc/kernel-doc-2.6.32/Documentation/scheduler/sched-design-CFS.txt

  • kernel.sched_min_granularity_ns
    sched_min_granularity_ns specifies the target minimum scheduler period in which a single task will run.  This tunable is used only when running load is high.  Unlike sched_latency_ns, this tunable specifies the target period allocated for each task to run rather than the time in which all tasks should be run once.

So the web page has already been fixed — it says “Updated 2018-08-30T21:11:42+00:00”; i.e., about four days ago; two weeks after you posted your question.

  • 1
    No I quoted it as is at the time of posting the question. As you observed, the content is updated now. – Chota Bheem Sep 3 '18 at 11:13
  • 1
    I apologize for jumping to conclusions; I have revised my answer to reflect your version of the timeline. – G-Man Sep 3 '18 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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