Изолировать причину более высокой загрузки ЦП на RHEL 6 против RHEL 5

В настоящее время я планирую перевести нашу систему с RHEL 5 на RHEL 6, но я столкнулся с проблемой с неожиданно высокой загрузкой ЦП на машинах RHEL 6. Похоже, что это может быть связано, по крайней мере, в какой-то степени с использованием 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 он будет использовать 0% загрузки ЦП, но на том же оборудовании, на котором установлен RHEL 6, он будет использовать около 0,5% ЦП, поэтому при запуске selectот 30 до 50 программ, использующих режим сна, он съедает большой объем процессора излишне.

Я открыл Bugzilla и попытался запустить OProfile, и он просто показывает 100% в основном для приложения и чуть более 99% в poll_idle при взгляде на ядро ​​(у меня в настройках grub установлен idle = poll, так что все может быть захвачено).

Любые другие идеи о том, что я могу сделать, чтобы попытаться определить причину более высокой загрузки ЦП?

ОБНОВЛЕНИЕ: я нашел инструмент 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

Похоже, что более высокая загрузка ЦП от планировщика. Я также использовал следующий скрипт bash, чтобы запустить 100 из них одновременно:

#!/bin/bash

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

На RHEL 5 загрузка ЦП остается близкой к 0%, но на RHEL 6 нетривиальная величина использования ЦП как пользователем, так и sys. Любые идеи о том, как отследить истинный источник этого и, надеюсь, исправить это?

Я также попробовал этот тест на текущей сборке Arch Linux и Ubuntu 11.10 и увидел похожее поведение, так что это похоже на проблему с ядром, а не просто на RHEL.

ОБНОВЛЕНИЕ 2: Я немного сомневаюсь, чтобы поднять это, потому что я знаю, что это большая дискуссия, но я опробовал ядро ​​с патчами BFS в Ubuntu 11.10, и оно не показывало такое же высокое использование ЦП системы (казалось, что использование ЦП пользователем то же).

Есть ли какой-нибудь тест, который я могу запустить с каждым из них, чтобы проверить, является ли такая высокая загрузка ЦП только разницей в учете использования ЦП, из-за которой он выглядит искусственно высоким? Или, если фактические циклы процессора украдены CFS?

ОБНОВЛЕНИЕ 3: Анализ, выполненный с использованием этого вопроса, похоже, указывает на то, что это связано с планировщиком, поэтому я создал новый вопрос для обсуждения результатов.

ОБНОВЛЕНИЕ 4: я добавил еще информацию к другому вопросу .

ОБНОВЛЕНИЕ 5: я добавил некоторые результаты к другому вопросу из более простого теста, который все еще демонстрирует проблему.

Ты спрашиваешь:

Есть ли какой-нибудь тест, который я могу запустить с каждым из них, чтобы проверить, является ли такая высокая загрузка ЦП только разницей в учете использования ЦП, из-за которой он выглядит искусственно высоким? Или, если фактические циклы процессора украдены CFS?

Что если вы запустили тест производительности процессора во время работы вашей test_select_smallпрограммы и посмотрите, изменяется ли его производительность в зависимости от версии ОС хоста?

Есть много вариантов: классический совет всегда «используйте что-то, что представляет тип нагрузки, которую вы будете иметь». Но крутые детки всегда просто использовали поврай