RHEL 6とRHEL 5でCPU使用率が高くなる原因を特定する

現在、システムを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がインストールされている同じハードウェアでは、CPUの約0.5％を使用selectするため、30〜50のプログラムを実行してスリープを実行すると、大量のCPUが不必要に。

Bugzillaを開いてOProfileを実行してみましたが、カーネルを見ると、アプリケーションのmainが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使用率の計算の違いであり、人為的に高く見えるようにしているかどうかをテストするために、それらのそれぞれで実行できるテストはありますか？それとも、実際のCPUサイクルがCFSによって盗まれているのですか？

UPDATE3：この質問に関連して行われた分析は、それがスケジューラーに関連していることを示しているようですので、結果を議論するために新しい質問を作成しました。

UPDATE4：他の質問に情報を追加しました。

UPDATE5：問題を示すより単純なテストの結果を他の質問に追加しました。

あなたが尋ねる：

この高いCPU使用率がCPU使用率の計算の違いであり、人為的に高く見えるようにしているかどうかをテストするために、それらのそれぞれで実行できるテストはありますか？それとも、実際のCPUサイクルがCFSによって盗まれているのですか？

test_select_smallプログラムの実行中にCPUベンチマークを実行し、そのパフォーマンスがホストOSのバージョンに応じて変化するかどうかを確認したらどうなるでしょうか。

選択肢はたくさんあります。古典的なアドバイスは、常に「自分が持つ負荷の種類を表すものを使用する」ことです。しかし、クールな子供たちは常にポヴレーを使いました