确定 RHEL 6 与 RHEL 5 上 CPU 使用率较高的原因

Question

我目前希望将我们的系统从 RHEL 5 迁移到 RHEL 6，但我遇到了一个问题，在 RHEL 6 机器上 CPU 使用率出乎意料地高。看来这可能至少在某种程度上是由于使用select来进行可中断的睡眠。这是一个显示行为的简单示例：

#include <sys/select.h>

int main()
{
  timeval ts;
  for (unsigned int ii=0; ii<10000; ++ii) {
    ts.tv_sec = 0;
    ts.tv_usec = 1000;
    select(0, 0, 0, 0, &ts);
  }

  return 0;
}

在 RHEL 5 机器上，它的 CPU 使用率将保持在 0%，但在安装了 RHEL 6 的同一硬件上，它将使用大约 0.5% 的 CPU，因此当运行 30 到 50 个程序select用于执行睡眠时，它会占用大量不必要的 CPU。

我打开了一个Bugzilla并尝试运行 OProfile，它在查看内核时仅在主应用程序中显示 100%，在 poll_idle 中显示超过 99%（我在我的 grub 选项中设置了 idle=poll，因此可以捕获所有内容）。

关于我可以做些什么来尝试隔离 CPU 使用率较高的原因的任何其他想法？

更新：我找到了 perf 工具并得到以下输出：

# Events: 23K cycles
#
# Overhead  Command        Shared Object                                Symbol
# ........  .......  ...................  ....................................
#
    13.11%  test_select_sma  [kernel.kallsyms]    [k] find_busiest_group
     5.88%  test_select_sma  [kernel.kallsyms]    [k] schedule
     5.00%  test_select_sma  [kernel.kallsyms]    [k] system_call
     3.77%  test_select_sma  [kernel.kallsyms]    [k] copy_to_user
     3.39%  test_select_sma  [kernel.kallsyms]    [k] update_curr
     3.22%  test_select_sma  ld-2.12.so           [.] _dl_sysinfo_int80
     2.83%  test_select_sma  [kernel.kallsyms]    [k] native_sched_clock
     2.72%  test_select_sma  [kernel.kallsyms]    [k] find_next_bit
     2.69%  test_select_sma  [kernel.kallsyms]    [k] cpumask_next_and
     2.58%  test_select_sma  [kernel.kallsyms]    [k] native_write_msr_safe
     2.47%  test_select_sma  [kernel.kallsyms]    [k] sched_clock_local
     2.39%  test_select_sma  [kernel.kallsyms]    [k] read_tsc
     2.26%  test_select_sma  [kernel.kallsyms]    [k] do_select
     2.13%  test_select_sma  [kernel.kallsyms]    [k] restore_nocheck

似乎更高的 CPU 使用率来自调度程序。我还使用以下 bash 脚本同时启动了其中的 100 个：

#!/bin/bash

for i in {1..100}
do
  ./test_select_small &
done

在 RHEL 5 上，CPU 使用率保持接近 0%，但在 RHEL 6 上，用户和系统的 CPU 使用率都非常高。关于如何追踪此问题的真正来源并希望修复它的任何想法？

我还在当前的 Arch Linux 版本和 Ubuntu 11.10 上尝试了这个测试，并看到了类似的行为，所以这似乎是某种类型的内核问题，而不仅仅是 RHEL 问题。

UPDATE2：我有点犹豫要不要提出这个问题，因为我知道这是一个巨大的争论，但是我在 Ubuntu 11.10 上尝试了一个带有 BFS 补丁的内核，但它没有显示出同样高的系统 CPU 使用率（用户 CPU 使用率似乎约为相同）。

是否有一些测试我可以与每个测试一起运行以测试这种高 CPU 使用率是否只是 CPU 使用率计算的差异，使其看起来人为地高？或者，如果 CFS 窃取了实际的 CPU 周期？

UPDATE3：涉及这个问题的分析似乎表明它与调度程序有关，所以我创建了一个新问题来讨论结果。

UPDATE4：我在另一个问题中添加了更多信息。

UPDATE5：我从一个更简单的测试中向另一个问题添加了一些结果，该测试仍然证明了这个问题。

Answer 1

你问：

我是否可以对它们中的每一个运行一些测试，以测试这种高 CPU 使用率是否只是 CPU 使用率计算上的差异导致它看起来人为地高？或者 CFS 是否窃取了实际的 CPU 周期？

如果您在运行test_select_small程序时运行 CPU 基准测试，并查看其性能是否会根据主机操作系统版本而变化，该怎么办？

有很多选择：经典的建议始终是“使用代表您将拥有的负载类型的东西”。但酷孩子总是只使用povray