问题标签 [cfs]

在 Linux 上，系统load被定义为 num runnable processes + num uninterruptable processes. 我想知道它是否会正确考虑用于限制一组进程在给定时间间隔内可能使用的 cpu 共享数量的CFS cgroup 配额。

换句话说：如果一个进程由于 CFS 配额耗尽而受到限制，它是否仍被视为可运行并因此反映在系统负载平均值中？

在 OpsCenter 6.0.3 中，我遇到了以下问题

'Services' -> 'Best Practice Service' -> 'Performance Service - Table Metrics Advisor' -> 'Secondary indexes cardinality'依次点击后出现上图。

在 DevCenter 中查看的inode表如下所示：

据我所知，[inode]链接跟踪每个文件的元数据和块位置。但是，我能做些什么来解决这个问题？

OpsCenter 版本：6.0.3 Cassandra 版本：2.1.15.1423 DataStax Enterprise 版本：4.8.10

我想运行一些定期且有一定期限的任务。我想看看 linux 调度程序 (CFS) 如何处理这些任务。我不想为此使用实时操作系统，但我想看看普通的 linux 系统如何对这些类型的工作负载做出反应，以及错过了哪些截止日期。

我该怎么做呢？

我遇到了允许类似的 SCHED_DEADLINE 。尽管它将任务视为 RT 并在作业上调用诸如 EDF 之类的 RT 调度算法。即便如此，我还是想尝试一下但失败了：

我收到此错误：

我正在研究 Linux CFS 调度程序，并遇到了这个名为sched_wakeup_granularity_ns. 如本文所述，其用法如下。

此参数控制任务的唤醒延迟，即它必须经过多长时间才能抢占当前任务。

从这里进一步查找此参数：

如果当前运行进程的虚拟运行时间与抢占进程的虚拟运行时间之差大于 sched_wakeup_granularity_ns 的虚拟运行时间（这里将 sched_wakeup_granularity_ns 转移到具有抢占进程权重的虚拟运行时间），则发生抢占。

在我的系统中这个默认值是 2.5 毫秒。

我的问题：如果一个截止日期 <= 2.5 毫秒的进程同时执行另一个低优先级进程，那么由于这个最小粒度，它将没有机会执行，并且总是会错过它的截止日期。

我的主张正确吗？为什么Linux内核是这样设计的？

当然我们可以把这个参数设置为 0 毫秒，然后重新编译内核，但是在日常生活中，2.5 毫秒期限的任务不是经常发生吗？视频解码器、声音处理应用程序和其他延迟关键工作负载 ?

在 CFS 的 PELT 中，以下参数用于计算 PELT。

"#define LOAD_AVG_MAX 47742 /* 最大可能负载平均 */"

"#define LOAD_AVG_MAX_N 345 /* 产生 LOAD_AVG_MAX 的完整周期数 */"

为什么是 LOAD_AVG_MAX 47742 ？

为什么是 LOAD_AVG_MAX_N 345 ？

我找不到关于这些参数的确切解释。你能详细解释一下吗？

我正在尝试查找 fair.c 文件来查看源代码以改进 CFS 算法。在互联网上，许多人建议查看 kernel/sched 文件夹。但是，只有 Makefile 文件。我在虚拟机上运行 ubuntu 16.0.4，内核版本是 4.10。我尝试通过进入 usr/src/linux-header-37-header/kernel/sched 任何想法..？？非常感谢您提前。

目前，我想深入研究 Linux 调度。我有一个带有 lubuntu 和 4.10.0-37-generic 内核的测试设置。我想知道 CFS 任务的最短执行时间可以多长时间而不会自行产生。这里很好地概述了如何调整调度程序。我认为 sysctl 参数 kernel.sched_min_granularity_ns (setup = 1.500.000) 是正确的查看位置。但我没有找到有关调度程序频率的任何参考。在 CFS 文档（CFS 文档) 调度的独立性和 jiffies （从系统定时器中断以 1/HZ 周期计算）。但是在一些文档中我再也找不到它了，内核中的所有频率都依赖于这个 HZ 值。我当前的 HZ 值为 250（默认值），因此如果在 jiffy 定时器中断内调用调度程序，则仅每 4 毫秒就会发生重新调度。这与 1.5 毫秒 sched_min_granularity_ns 形成对比。调度程序如何比系统中断更快？

对这个错误有一点帮助吗？

我在 R 中运行 CFS 时得到它

运行代码：

其中df是数据集，Target和best_features是不言自明的。

错误：

根据我目前对 Linux CFS 的了解，调度实体由它们vruntime在 RB-tree 中的虚拟运行时 ( ) 进行索引。

vruntime调度程序通过调用update_curr基本上增加当前运行实体的 vruntime 值的函数来定期更新它。

我不明白的是调度程序如何使 RB-tree 始终井井有条。该update_curr函数增加了 的值，vruntime但似乎并未检查实体是否应移回 RB-tree 的右侧。哪个函数执行此检查？

在 Linux 中，两个具有相同优先级的 SCHED_FIFO 任务是否在每个周期内获得处理时间，并且在周期结束之前都没有完成任务？

Linux 文档说 SCHED_FIFO 进程只能被具有更高优先级的进程抢占，但我的理解是 CFS 在更高层上运行，并在每个周期内为两个任务中的每一个分配时隙。