Izolowanie przyczyny większego wykorzystania procesora na RHEL 6 w porównaniu z RHEL 5

Obecnie szukam możliwości przeniesienia naszego systemu z RHEL 5 na RHEL 6, ale wpadłem w kłopoty z nieoczekiwanie wysokim zużyciem procesora na maszynach RHEL 6. Wydaje się, że może to wynikać przynajmniej w części z zastosowania selectprzerywanego snu. Oto prosty przykład, który pokazuje zachowanie:

#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;
}

Na maszynie RHEL 5 pozostanie na poziomie 0% użycia procesora, ale na tym samym sprzęcie z zainstalowanym RHEL 6 zużyje około 0,5% procesora, więc gdy 30 do 50 programów uruchomi się, selectaby wykonać sen, zjada duża ilość procesora niepotrzebnie.

Otworzyłem Bugzilla i starałem działa oprofile i to po prostu pokazuje 100% w głównym za stosowanie i nieco ponad 99% w poll_idle patrząc na jądra (mam bezczynności = ankietę zestaw w moich opcji łba, więc wszystko może być zrobione).

Jakieś inne pomysły na to, co mogę zrobić, aby spróbować ustalić przyczynę wyższego wykorzystania procesora?

AKTUALIZACJA: Znalazłem narzędzie perf i otrzymałem następujące dane wyjściowe:

# 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

Wygląda na to, że wyższe użycie procesora wynika z harmonogramu. Użyłem również następującego skryptu bash, aby uruchomić 100 z nich jednocześnie:

#!/bin/bash

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

Na RHEL 5 użycie procesora utrzymuje się na poziomie 0%, ale na RHEL 6 zużycie zasobów procesora zarówno przez użytkownika, jak i system jest nietrywialne. Jakieś pomysły, jak znaleźć prawdziwe źródło tego i mam nadzieję, że to naprawić?

Próbowałem również tego testu na bieżącej kompilacji Arch Linux i Ubuntu 11.10 i zobaczyłem podobne zachowanie, więc wydaje się, że jest to jakiś problem z jądrem, a nie tylko problem RHEL.

UPDATE2: Waham się trochę, aby to poruszyć, ponieważ wiem, że to wielka debata, ale wypróbowałem jądro z łatami BFS na Ubuntu 11.10 i nie wykazywało takiego samego wysokiego zużycia procesora przez system (użycie procesora przez użytkownika wydawało się to samo).

Czy jest jakiś test, który mogę przeprowadzić z każdym z nich, aby sprawdzić, czy to wysokie użycie procesora jest tylko różnicą w rozliczaniu użycia procesora, które sprawia, że ​​wygląda on sztucznie wysoko? A może CFS kradnie faktyczne cykle procesora?

AKTUALIZACJA3: Analiza przeprowadzona na tym pytaniu wydaje się wskazywać, że jest to coś związanego z harmonogramem, więc stworzyłem nowe pytanie, aby omówić wyniki.

AKTUALIZACJA 4: Dodałem trochę więcej informacji do drugiego pytania .

AKTUALIZACJA5: Dodałem kilka wyników do drugiego pytania z prostszego testu, który wciąż pokazuje problem.

Ty pytasz:

Czy jest jakiś test, który mogę przeprowadzić z każdym z nich, aby sprawdzić, czy to wysokie użycie procesora jest tylko różnicą w rozliczaniu użycia procesora, które sprawia, że ​​wygląda on sztucznie wysoko? A może CFS kradnie faktyczne cykle procesora?

Co się stanie, jeśli uruchomisz test porównawczy procesora podczas uruchamiania test_select_smallprogramu i zobaczysz, czy jego wydajność zmienia się w zależności od wersji systemu operacyjnego hosta?

Istnieje wiele możliwości wyboru: klasyczna rada to zawsze „użyj czegoś, co reprezentuje rodzaj obciążenia, jakie będziesz mieć”. Ale fajne dzieciaki zawsze używały povray