我有一个 Linux 系统，我们使用 cgroups 创建两个 cpu_exclusive cpuset，A 和 B，并且我们将所有用户线程和所有未绑定内核线程迁移到附加到 cpuset A 的 cgroup。在 cpuset A 中运行的事物具有不同的调度程序策略和不同的优先级，并且 cpuset A 中运行的线程比 cpuset A 中的内核多得多。
还有一些少量非常活跃的进程附加到 cpuset B，其中这些进程上的用户线程总数永远不会大于 cpuset B 中独占可用的核心数量。目标是屏蔽 cpuset 中运行的这些重要任务B 免受机器上的其他活动的影响并最大限度地减少处理延迟。
在这样的设置中，CPUset B 中运行的用户线程的调度策略/优先级是否有任何可观察到的影响？换句话说：将 B cpuset 线程的调度策略从默认的 SCHED_OTHER 更改为 SCHED_FIFO 或 SCHED_RR 会产生任何后果（好还是坏）？
似乎答案应该是“否”，因为调度程序应该能够为 cpuset B 中运行的每个线程分配其自己的专用核心，因此不会有任何优先级或调度，因此 B 的策略和相对优先级cpuset 线程并不重要。另一方面，还有绑定的内核线程和“调度程序域”方面需要担心，可能还有其他我没有考虑过的事情。
在过度配置的独占 cpuset 中运行的线程的调度策略和优先级在实际意义上是否重要？
答案1
所使用的时间片对于需要缓存持久性的 CPU 密集型作业很重要，除非您将特定核心锁定到每个 PID。您可以使用调度程序策略 SCHED_BATCH 增加时间片，在某些情况下将性能提高高达 300%，同时降低交互响应能力。 SCHED_RR 会产生较小时间片的相反效果（这会降低吞吐量，但会提高实时响应能力）。
您可以使用 schedtool 作为单个命令为集合 B 中的所有 PID 设置特定 PID 的策略。它还可以用于将特定 PID 锁定到特定核心，这将是最佳解决方案，因为这样缓存持久性不再依赖于时间片，但这需要更多努力，因为您必须为每个 PID 运行单独的 schedtool 命令。
答案2
如果每个进程都有自己的核心，那么就没有优先级限制。
但是，如果您安排一个流程每 15 分钟运行一次 30 分钟，您将开始需要确定优先级，因为该流程将开始重叠。
然而，不存在“最佳”调度策略。
它们实际上取决于您想要实现的目标。但一开始，我会将其保留为默认值 SCHED_OTHER，并观察一段时间，然后再尝试更专业的东西。