c++ - SCHED_RR 线程上的 Posix 计时器正在使用 100% CPU

Question

我有以下代码片段:

#include <iostream>
#include <thread>

#include <unistd.h>
#include <sys/epoll.h>
#include <sys/timerfd.h>

int main() {
    std::thread rr_thread([](){
      struct sched_param params = {5};
      pthread_setschedparam(pthread_self(), SCHED_RR, &params);

      struct itimerspec ts;
      struct epoll_event ev;
      int tfd ,epfd;

      ts.it_interval.tv_sec = 0;
        ts.it_interval.tv_nsec = 0;
        ts.it_value.tv_sec = 0;
        ts.it_value.tv_nsec = 20000; // 50 kHz timer

      tfd = timerfd_create(CLOCK_MONOTONIC, 0);
      timerfd_settime(tfd, 0, &ts, NULL);
      epfd = epoll_create(1);

      ev.events = EPOLLIN;
      epoll_ctl(epfd, EPOLL_CTL_ADD, tfd, &ev);

      while (true) {
        epoll_wait(epfd, &ev, 1, -1); // wait forever for the timer
        read(tfd, &missed, sizeof(missed));

        // Here i have a blocking function (dummy in this example) which
        // takes on average 15ns to execute, less than the timer period anyways
        func15ns();
      }

    });

    rr_thread.join();
}

我有一个使用 SCHED_RR 策略的 posix 线程，在这个线程上有一个 POSIX 定时器运行，超时为 20000ns = 50KHz = 50000 ticks/sec。

在定时器触发后，我正在执行一个函数，它花费的时间比定时器周期少大约 15 纳秒，但这并不重要。

当我执行此命令时，我的 CPU 使用率达到 100%，整个系统变慢，但我不明白为什么会发生这种情况，有些事情令人困惑。

1. 为什么 CPU 使用率为 100%，因为线程应该在等待计时器触发时休眠，所以理论上可以安排其他任务，对吧？即使这是一个高优先级线程。

2. 我使用 pidstat 检查了上下文切换的数量，它似乎非常小，接近于 0，包括自愿和非自愿的。这是正常的吗？在等待计时器触发时，调度程序应该安排其他任务吗？我应该至少看到 20000 * 2 个上下文切换/秒

Answer 1

如前所述，您的程序并不像您描述的那样运行。这是因为您将定时器编程为一次性定时器，而不是重复定时器。对于每 20000 ns 触发一次的计时器，您要设置 20000 ns 的间隔:

    ts.it_interval.tv_nsec = 20000;

修改后，我得到了一个可以在一个核心上产生高负载的程序。

1. Why 100% CPU Usage since the thread is supposed to be sleeping while waiting for the timer to fire, so other tasks can be scheduled in theory right? even if this is a high priority thread.

当然，您的线程会在 epoll_wait() 中阻塞以等待计时器计时，如果事实上它设法在计时器再次计时之前循环回到那里。在我的机器上，你的程序只消耗了一个内核的 30% 左右，这似乎证实了这种阻塞确实会发生。您看到 100% 的 CPU 使用表明我的计算机运行该程序的效率比您的计算机高，无论出于何种原因。

但是您必须意识到负载非常很重。您要求每 20000 ns 执行一次计时器本身的所有处理、epoll 调用、读取和 func15ns() 一次。是的，无论剩余多少时间(如果有的话)都可以安排用于另一项任务，但任务交换又会花费更多时间。 20000 ns 不是很多时间。考虑一下 fetching a word from main memory costs about 100 ns (虽然从缓存中读取一个当然更快)。

特别是不要忽略func15ns()以外的工作。如果后者确实只需要 15 ns 就可以运行，那么它是你最不用担心的。您正在执行两个系统调用，这些调用很昂贵。究竟有多昂贵取决于很多因素，但考虑到删除 epoll_wait() 调用将我的负载从核心的 30% 减少到 25%(请注意，整个 epoll 设置是多余的在这里是因为简单地允许 read() 阻塞就达到了目的)。

2. I checked using pidstat the number of context switches and it seems that it's very small, close to 0, both voluntary and involuntary ones. Is this normal? While waiting for the timer to fire the scheduler should schedule other tasks right? I should see at least 20000 * 2 context switches / sec

你正在为一个高优先级任务占用一个完整的 CPU，那你为什么期望切换？

另一方面，我还观察到运行您的(修改后的)程序的进程的上下文切换次数很少，即使它仅占用核心的 25%。我现在还没准备好解释为什么会这样。