“高度非自愿上下文”切换是什么意思？答案

【问题标题】：What does "high involuntary context" switches mean?“高度非自愿上下文”切换是什么意思？
【发布时间】：2014-03-13 16:48:21
【问题描述】：

我用 C 语言重新编写了一部分代码。在使用 getrusage(2) C API 记录资源使用情况来测试它时。

更改代码之前：

user time (ms): 21503
system time (ms): 372
involuntary context switches: 20

更改后：

user time (ms): 25589
system time (ms): 80732
involuntary context switches: 821

我看到很多involuntary context switches 在我重新编写的代码中完成。

我的问题不是关于如何减少上下文切换。但是..

当“非自愿上下文切换”更多时会发生什么？
它将以何种方式影响系统？

P.S：磁盘上没有任何活动，因为没有写入任何内容。它只是多次ping服务器。

更新：

添加了系统和用户时间。

程序是多线程的。在这两种情况下都会产生相同数量的线程（3k 线程）。只有 C 中的底层 api 被重写。

【问题讨论】：

标签： c++ c linux performance unix

【解决方案1】：

只要线程/进程进行阻塞的系统调用，就会发生自愿上下文切换。

当线程运行时间过长（通常是 10 毫秒）而没有进行阻塞的系统调用并且有进程在等待 CPU 时，会发生非自愿的上下文切换。

看起来您的程序现在比以前更占用 CPU。如果您已将其设为多线程，则可能会增加。

821 上下文切换 - 取决于程序的执行时间，这可能会也可能不会很多。

如果您想减少上下文切换的数量，您可以减少工作线程的数量，这样线程的数量就会少于 CPU 内核的数量。

更新

假设两种情况下的负载相同，看起来代码修改增加了 cpu 使用率。如果增加的负载是一个问题，您应该分析代码以找到瓶颈。 Instrumentation 有助于找出导致问题的代码部分。

【讨论】：

【解决方案2】：

这不是您问题的确切答案。无论如何，@Klas 指出

线程运行时发生非自愿上下文切换太长了

所以我的想法是你可以检查你的线程运行时间过长。使用 perf 并在代码中查找最常发生上下文切换的位置。并且可能将旧版本程序的测量值与新版本进行比较。

Perf (https://perf.wiki.kernel.org/index.php/Tutorial) 有事件context-switches。您可以测量它并在它发生的地方收集堆栈跟踪。这是测量上下文切换的示例：

perf record -e cs -g -p `pidof my_test` sleep 5

然后检查它们发生的位置。例如，有一个 C++ 程序带有一个不定式循环，根本没有系统调用。所有开关内容都有来自我的函数my_thread_func的stracetrace：

perf report --stdio -g --kallsym=/boot/System.map-2.6.32-431.el6.x86_64

# Samples: 7  of event 'cs'
# Event count (approx.): 7
#
# Overhead  Command      Shared Object                         Symbol
# ........  .......  .................  .............................
#
   100.00%  my_test  [kernel.kallsyms]  [k] perf_event_task_sched_out
            |
            --- perf_event_task_sched_out
                schedule
                retint_careful
                my_thread_func(void*)

相反，这是对具有大量系统调用的不定式循环的 C++ 程序的测量：

# Samples: 6  of event 'cs'
# Event count (approx.): 6
#
# Overhead          Command      Shared Object                         Symbol
# ........  ...............  .................  .............................
#
   100.00%  my_test_syscall  [kernel.kallsyms]  [k] perf_event_task_sched_out
            |
            --- perf_event_task_sched_out
                schedule
               |
               |--83.33%-- sysret_careful
               |          syscall
               |
                --16.67%-- retint_careful
                          syscall

【讨论】：