Причина, що збільшує використання процесора на 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 при перегляді ядра (у моєму режимі холостого ходу = опитування встановлено, щоб все було захоплено).

Будь-які інші ідеї, що я можу зробити, щоб спробувати і виділити, що є причиною більшого використання процесора?

ОНОВЛЕННЯ: Я знайшов інструмент 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 існує нетривіальна кількість використання процесора як у користувача, так і в системі. Будь-які ідеї, як знайти справжнє джерело цього та сподіватися виправити це?

Я також спробував цей тест на поточній збірці Arch Linux та Ubuntu 11.10 і побачив подібну поведінку, тому це, здається, є деяким типом проблеми з ядром, а не лише проблемою RHEL.

UPDATE2: Я трохи вагаюся, щоб донести це, бо знаю, що це велика дискусія, але я спробував ядро ​​з патчами BFS на Ubuntu 11.10, і воно не показало такого ж високого використання системного процесора (використання процесорних процесів у користувача, здавалося, так само).

Чи є якийсь тест, який я можу запустити з кожним із них, щоб перевірити, чи це високе використання процесора - це лише різниця в обліку використання процесора, завдяки чому він виглядає штучно високим? Або, якщо фактичні цикли процесора викрадаються CFS?

ОНОВЛЕННЯ3: Проведений аналіз, що стосується цього питання, схоже, вказує на те, що це щось пов'язане з планувальником, тому я створив нове запитання для обговорення результатів.

UPDATE4: До іншого питання я додав ще трохи інформації .

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

Ви запитаєте:

Чи є якийсь тест, який я можу запустити з кожним із них, щоб перевірити, чи це високе використання процесора - це лише різниця в обліку використання процесора, завдяки чому він виглядає штучно високим? Або, якщо фактичні цикли процесора викрадаються CFS?

Що робити, якщо ви запустили орієнтир CPU під час запуску test_select_smallпрограми, і побачите, чи змінюється її продуктивність залежно від версії хост-операційної системи?

Є багато варіантів: класична порада - це завжди "використовувати те, що представляє собою навантаження, яку ти матимеш". Але круті діти завжди просто використовували povray