分配给特定进程may vary的量程：
您可以通过调整sched_latency_ns和sched_min_granularity_ns来调整“slice”，但请注意，“slice”不是固定的量程。还要注意，CFS抢占决策是基于瞬时状态的。一个任务可能已经收到了一个完整的（可变的）CPU时间“切片”，但是只有当一个更值得的任务可用时才会触发抢占，所以“切片”并不是你所期望的“最大不间断CPU时间”。但它有点类似。
这是因为默认的Linux调度程序Completely Fair Scheduler将一定比例的处理器分配给进程，而不是固定的时间片。这意味着每个进程的时间片与当前负载成比例，并由进程的优先级值加权。
对于使用SCHED_RR的专用实时进程，Linux内核中的默认时间片定义为include/linux/sched/rt.h中的RR_TIMESLICE。

/*
 * default timeslice is 100 msecs (used only for SCHED_RR tasks).
 * Timeslices get refilled after they expire.
 */
#define RR_TIMESLICE            (100 * HZ / 1000)

您可以使用sched_rr_get_interval()获取特定SCHED_RR进程的SCHED_RR间隔。

CFS（进程的默认调度程序）没有固定的时间片，它是在运行时根据目标延迟（sysctl_sched_latency）和正在运行的进程数计算的。时间片不能小于最小粒度（sysctl_sched_min_granularity）。
时间片将始终在sysctl_sched_min_granularity和sysctl_sched_latency之间，这两个值的默认值分别为0.75 ms和6 ms，并在kernel/sched/fair. c中定义。
但实际的时间片不会导出到用户空间。

在SCHED_OTHER进程（即在（默认）非实时循环分时策略下运行的进程）和SCHED_RR进程之间的公认答案中存在一些混淆。
sched_latency_ns和sched_min_granularity_ns文件（用于调试目的，只有在内核配置了CONFIG_SCHED_DEBUG时才可见）影响SCHED_OTHER进程的调度。正如Alexey Shmalko的回答中所指出的，CFS下的时间片不是固定的（并且不导出到用户空间），并且将取决于内核参数和进程的nice值等因素。
sched_rr_get_interval()返回一个固定值，这是SCHED_RR进程保证获得的时间量，除非它被抢占或阻塞。在传统的Linux上，SCHED_RR时间量是0.1秒。从Linux 3.9开始，可以通过/proc/sys/kernel/sched_rr_timeslice_ms文件调整限制，其中量程表示为毫秒值，默认值为100。

我试图google这个问题在Linux中的SCHED_RR时间片的相同疑问，但我没有得到明确的答案，无论是从这里还是从内核的源代码。
经过进一步检查，我发现关键点是RR_TIMESLICE是jiffies中的默认时间片，而不是毫秒！因此，SCHED_RR的默认时间片始终是100 ms，无论您配置了什么HZ。
与/proc/sys/kernel/sched_rr_timeslice_ms的值相同，输入值单位为毫秒，但存储和输出单位为jiffies！
因此，当设置CONFIG_HZ=100时，您会发现：

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

有点困惑，希望这能帮助你理解它！

sysctl用于在运行时读写内核参数。可用参数是/proc/sys/下列出的参数。Linux 3.9还添加了一个新的机制来调整（和查看）SCHED_RR量程：proc/sys/kernel/sched_rr_timeslice_ms文件将量程显示为毫秒值，默认值为100。将0写入此文件会将量程重置为默认值。所以你可能想试试：

sysctl kernel.sched_rr_timeslice_ms