我正在寻找我的Linux内核的时间片(或量子)的值。具体问题:
/proc
r3i60tvu1#
分配给特定进程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。
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间隔。
sched_rr_get_interval()
8oomwypt2#
CFS(进程的默认调度程序)没有固定的时间片,它是在运行时根据目标延迟(sysctl_sched_latency)和正在运行的进程数计算的。时间片不能小于最小粒度(sysctl_sched_min_granularity)。时间片将始终在sysctl_sched_min_granularity和sysctl_sched_latency之间,这两个值的默认值分别为0.75 ms和6 ms,并在kernel/sched/fair. c中定义。但实际的时间片不会导出到用户空间。
sysctl_sched_latency
sysctl_sched_min_granularity
2wnc66cl3#
在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。
SCHED_OTHER
SCHED_RR
sched_latency_ns
sched_min_granularity_ns
CONFIG_SCHED_DEBUG
/proc/sys/kernel/sched_rr_timeslice_ms
i7uq4tfw4#
我试图google这个问题在Linux中的SCHED_RR时间片的相同疑问,但我没有得到明确的答案,无论是从这里还是从内核的源代码。经过进一步检查,我发现关键点是RR_TIMESLICE是jiffies中的默认时间片,而不是毫秒!因此,SCHED_RR的默认时间片始终是100 ms,无论您配置了什么HZ。与/proc/sys/kernel/sched_rr_timeslice_ms的值相同,输入值单位为毫秒,但存储和输出单位为jiffies!因此,当设置CONFIG_HZ=100时,您会发现:
HZ
CONFIG_HZ=100
# echo 100 > /proc/sys/kernel/sched_rr_timeslice_ms # cat /proc/sys/kernel/sched_rr_timeslice_ms 10
有点困惑,希望这能帮助你理解它!
h9vpoimq5#
sysctl用于在运行时读写内核参数。可用参数是/proc/sys/下列出的参数。Linux 3.9还添加了一个新的机制来调整(和查看)SCHED_RR量程:proc/sys/kernel/sched_rr_timeslice_ms文件将量程显示为毫秒值,默认值为100。将0写入此文件会将量程重置为默认值。所以你可能想试试:
sysctl
/proc/sys/
sysctl kernel.sched_rr_timeslice_ms
5条答案
按热度按时间r3i60tvu1#
分配给特定进程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
。您可以使用
sched_rr_get_interval()
获取特定SCHED_RR进程的SCHED_RR间隔。8oomwypt2#
CFS(进程的默认调度程序)没有固定的时间片,它是在运行时根据目标延迟(
sysctl_sched_latency
)和正在运行的进程数计算的。时间片不能小于最小粒度(sysctl_sched_min_granularity
)。时间片将始终在
sysctl_sched_min_granularity
和sysctl_sched_latency
之间,这两个值的默认值分别为0.75 ms和6 ms,并在kernel/sched/fair. c中定义。但实际的时间片不会导出到用户空间。
2wnc66cl3#
在
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。i7uq4tfw4#
我试图google这个问题在Linux中的
SCHED_RR
时间片的相同疑问,但我没有得到明确的答案,无论是从这里还是从内核的源代码。经过进一步检查,我发现关键点是
RR_TIMESLICE
是jiffies中的默认时间片,而不是毫秒!因此,SCHED_RR
的默认时间片始终是100 ms,无论您配置了什么HZ
。与
/proc/sys/kernel/sched_rr_timeslice_ms
的值相同,输入值单位为毫秒,但存储和输出单位为jiffies!因此,当设置
CONFIG_HZ=100
时,您会发现:有点困惑,希望这能帮助你理解它!
h9vpoimq5#
sysctl
用于在运行时读写内核参数。可用参数是/proc/sys/
下列出的参数。Linux 3.9还添加了一个新的机制来调整(和查看)SCHED_RR量程:proc/sys/kernel/sched_rr_timeslice_ms文件将量程显示为毫秒值,默认值为100。将0写入此文件会将量程重置为默认值。所以你可能想试试: