Question

我试图了解linux perf，发现了一些令人困惑的行为：

我写了一个简单的多线程示例，每个线程固定一个线程；每个线程都在本地运行计算，并且彼此之间不通信（请参见下面的test.cc）。我当时在想这个例子应该有很低的上下文切换，即使不是零。但是，使用linux perf对示例进行概要分析可以显示成千上万的上下文切换-比我期望的要多得多。我进一步剖析了linux命令sleep 20进行比较，显示了更少的上下文切换。

此个人资料结果对我来说没有任何意义。是什么导致了如此多的上下文切换？

> sudo perf stat -e sched:sched_switch ./test
 Performance counter stats for './test':

                 6,725  sched:sched_switch                                          

      20.835 seconds time elapsed

> sudo perf stat -e sched:sched_switch sleep 20

 Performance counter stats for 'sleep 20':

                 1      sched:sched_switch                                          

      20.001 seconds time elapsed

为重现结果，请运行以下代码：

perf stat -e context-switches sleep 20
perf stat -e context-switches ./test

要编译源代码，请键入以下代码：

g++ -std=c++11 -pthread -o test test.cc

// test.cc
#include <iostream>
#include <thread>
#include <vector>

int main(int argc, const char** argv) {
  unsigned num_cpus = std::thread::hardware_concurrency();
  std::cout << "Launching " << num_cpus << " threads\n";

  std::vector<std::thread> threads(num_cpus);
  for (unsigned i = 0; i < num_cpus; ++i) {
    threads[i] = std::thread([i] {
      int j = 0;
      while (j++ < 100) {
        int tmp = 0;
        while (tmp++ < 110000000) { }
      }
    });

    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(i, &cpuset);
    int rc = pthread_setaffinity_np(threads[i].native_handle(),
                                    sizeof(cpu_set_t), &cpuset);
    if (rc != 0) {
      std::cerr << "Error calling pthread_setaffinity_np: " << rc << "\n";
    }
  }

  for (auto& t : threads) {
    t.join();
  }
  return 0;
}

Answer 1

我们无法确切告知您计划的时间-但是您可以使用perf来了解自己。

perf record -e sched:sched_switch ./test

请注意，这需要安装的debugfs和root权限。现在，perf report将为您提供有关调度程序将要切换到的内容的概述（有关完整列表，请参见perf script）。现在，您的代码中没有明显的东西会引起上下文切换（例如，睡眠，等待I / O），因此很可能在这些内核上安排了另一项任务。

sleep几乎没有上下文切换的原因很简单。它几乎立即进入睡眠状态-这是一个上下文切换。该任务处于非活动状态时，不能被其他任务取代。

Answer 2

您可以使用sudo perf sched record -- ./test来确定要安排运行哪些进程来代替应用程序的线程之一。当我在系统上执行此命令时，我得到：

sudo perf sched record -- ./test
Launching 4 threads
[ perf record: Woken up 10 times to write data ]
[ perf record: Captured and wrote 23.886 MB perf.data (212100 samples) ]

请注意，我有四个核心，可执行文件的名称为test。 perf sched已对所有与调度程序有关的事件进行了采样，并默认将数据转储到名为perf.data的文件中。该文件的大小约为23 MB，其中包含212100个采样事件。采样的持续时间为perf开始到test终止的时间。

您可以使用sudo perf sched map以如下所示的良好格式打印所有记录的事件：

             *.         448826.757400 secs .  => swapper:0
              *A0       448826.757461 secs A0 => perf:15875
          *.   A0       448826.757477 secs 
  *.       .   A0       448826.757548 secs 
   .       .  *B0       448826.757601 secs B0 => migration/3:22
   .       .  *.        448826.757608 secs 
  *A0      .   .        448826.757625 secs 
   A0     *C0  .        448826.757775 secs C0 => rcu_sched:7
   A0     *.   .        448826.757777 secs 
  *D0      .   .        448826.757803 secs D0 => ksoftirqd/0:3
  *A0      .   .        448826.757807 secs 
   A0 *E0  .   .        448826.757862 secs E0 => kworker/1:3:13786
   A0 *F0  .   .        448826.757870 secs F0 => kworker/1:0:5886
   A0 *G0  .   .        448826.757874 secs G0 => hud-service:1609
   A0 *.   .   .        448826.758614 secs 
   A0 *H0  .   .        448826.758714 secs H0 => kworker/u8:2:15585
   A0 *.   .   .        448826.758721 secs 
   A0  .  *I0  .        448826.758740 secs I0 => gnome-terminal-:8878
   A0  .   I0 *J0       448826.758744 secs J0 => test:15876
   A0  .   I0 *B0       448826.758749 secs

两个字母的名称A0，B0，C0，E0等是perf给运行中的每个线程的简称在系统上。前四列显示了四个内核中的每个内核上正在运行哪个线程。例如，在倒数第二行中，您可以看到在for循环中创建的第一个线程。分配给该线程的名称为J0。该线程在第四个内核上运行。星号表示它刚从其他线程上下文切换到。如果没有星号，则表示同一线程继续在同一内核上运行另一个时间片。点代表空闲的核心。要确定所有四个线程的名称，请运行以下命令：

sudo perf sched map | grep 'test'

在我的系统上，将打印：

   A0  .   I0 *J0       448826.758744 secs J0 => test:15876
   J0  A0 *K0  .        448826.758868 secs K0 => test:15878
   J0 *L0  K0  .        448826.758889 secs L0 => test:15877
   J0  L0  K0 *M0       448826.758894 secs M0 => test:15879

现在，您知道分配给线程（和所有其他线程）的两个字母的名称。您可以确定哪些其他线程正在使您的线程进行上下文切换。例如，如果您看到以下内容：

  *G1  L0  K0  M0       448826.822555 secs G1 => firefox:2384

然后您会知道三个应用程序线程正在运行，但是其中一个核心用于运行Firefox。因此，第四个线程需要等待，直到调度程序决定何时再次调度。

如果您希望所有调度程序插槽中至少有一个线程被占用，则可以使用以下命令：

sudo perf sched map > mydata
grep -E 'J0|K0|L0|M0' mydata > mydata2
wc -l mydata
wc -l mydata2

最后两个命令告诉您应用程序的至少一个线程正在运行多少行（时间片）。您可以将其与时间片总数进行比较。由于有四个核心，因此调度程序插槽的总数为4 *（时间片数量）。然后，您可以进行各种手动计算，并准确地了解发生了什么。

为什么perf具有如此高的上下文切换？

2 个答案: