为什么每秒进行一次非自愿上下文切换？答案

【问题标题】：Why one non-voluntary context switch per second?为什么每秒进行一次非自愿上下文切换？
【发布时间】：2012-12-26 06:58:33
【问题描述】：

操作系统是 RHEL 6 (2.6.32)。我已经隔离了一个核心，并在其上运行了一个计算密集型线程。 /proc/{thread-id}/status 每秒显示一次非自愿上下文切换。

有问题的线程是 SCHED_NORMAL 线程，我不想更改它。

如何减少非自愿上下文切换的次数？这是否取决于 /proc/sys/kernel 中的任何调度参数？

编辑：一些回复建议了替代方法。在走这条路之前，我首先想了解为什么即使在运行数小时后，我每秒也只能获得一次非自愿的上下文切换。例如，这是由 CFS 引起的吗？如果有，有哪些参数以及如何使用？

EDIT2：进一步澄清 - 我想回答的第一个问题如下：为什么我每秒进行一次非自愿上下文切换，而不是说，每半或两次切换一次秒？

【问题讨论】：

你为什么要关心？在现代系统中，即使每秒 100 次上下文切换也是噪音。
它的金融应用程序的延迟非常高，每个上下文切换可能是一个（或更多）失去的机会。我想了解哪些系统调优参数决定了独立内核上计算密集型线程的非自愿上下文切换率。
它很可能在锁、正常磁盘 I/O 或页面错误时阻塞。
这些都不是。该速率恰好是运行数小时内每秒一次的非自愿上下文切换。我几乎可以肯定 CFS 正在这样做 - 但基于什么调度参数？
就像@DavidSchwartz 所说，如果这是一个问题，你需要一个专用的盒子和一个实时操作系统，而不是一个通用的桌面。由于实现了良好的 I/O 性能，上下文切换几乎总是获得机会。 “每秒一次非自愿上下文切换” - 什么？正如大卫所说，谁在乎呢？优化一些重要的东西......

标签： linux-kernel operating-system scheduling kernel

【解决方案1】：

这是一个猜测，但有根据 - 因为你使用一个独立的 CPU，所以调度程序不会在它上面调度除你自己的任务之外的任何任务，但有一个例外 - 内核中的 vmstat 代码有一个计时器，用于调度单个工作队列每个 CPU 上的项目每秒一次以计算内存使用统计信息，这就是您所看到的每秒安排的内容。

工作队列代码足够智能，不会在内核 100% 空闲时不调度工作队列内核线程，但如果它正在运行单个任务则不会。

您可以使用ftrace 验证这一点。如果 sched_switch 跟踪器显示您每隔一秒左右切换一次的实体（该值四舍五入到最接近的 jiffie 事件，并且当 cpu 空闲时计时器不计数，因此这可能会扭曲计时）是 events/CPU_NUMBER 任务（或旧内核的 keventd），那么几乎 100% 的原因确实是 vmstat_update 函数将其计时器设置为每秒对事件内核线程运行的工作队列项进行排队。

请注意，vmstat 设置其计时器的周期是可配置的 - 您可以通过 vm.stat_interval sysctl 旋钮将其设置为其他值。增加此值会降低此类中断的发生率，但会降低内存使用统计的准确性。

我维护一个 wiki，其中包含隔离 CPU 工作负载 here 的所有中断源。如果在一个 vmstat 工作队列运行到下一个运行之间没有变化，我也有一个补丁可以让 vmstat 不安排工作队列项目 - 例如，如果你在 CPU 上的单个任务不使用任何动态内存，就会发生这种情况分配。不过，不确定它是否会对您有益 - 这取决于您的工作量。

【讨论】：

【解决方案2】：

我强烈建议您尝试优化代码本身，以便当它在 CPU 上运行时，您可以充分利用它。
无论如何，我不确定这是否可行，但还是试试看，让我们知道：

我基本上要做的就是将调度策略设置为 FIFO，然后为进程提供可能的最大优先级。

#include<sched.h>
struct sched_param sp = sched_get_priority_max(SCHED_FIFO);
int ret;

ret = sched_setscheduler(0, SCHED_FIFO, &sp);
if (ret == -1) {
  perror("sched_setscheduler");
  return 1;
}

请记住，您的进程所做的任何阻塞语句很可能会导致调度程序将其从 CPU 中取出。

Source
Man page
编辑：
抱歉，刚刚注意到pthread 标签；这个概念仍然成立，因此请查看此手册页： http://www.kernel.org/doc/man-pages/online/pages/man3/pthread_setschedparam.3.html

【讨论】：

你能告诉我为什么我在没有阻塞语句的代码中恰好看到一个非自愿的上下文切换吗？
我不确定，但可能是调度程序正在使用 RR 算法并且您的进程的时间片已经结束，所以您被分派然后再次回到 CPU 上。

【解决方案3】：

如果你的专用 CPU 上每秒一个中断仍然太多，那么你真的不需要通过正常的调度程序。我是否可以建议实时和同步优先级，与通常的抢先机制相比，它可以让您的流程更可靠地安排好？

【讨论】：