Causa isolante del maggiore utilizzo della CPU su RHEL 6 vs RHEL 5

Attualmente sto cercando di spostare il nostro sistema da RHEL 5 a RHEL 6, ma mi sono imbattuto in un intoppo con un utilizzo della CPU inaspettatamente elevato sulle macchine RHEL 6. Sembra che ciò possa essere dovuto almeno in parte all'uso di selectun sonno interrompibile. Ecco un semplice esempio che mostra il comportamento:

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

Su una macchina RHEL 5 rimarrà allo 0% di utilizzo della CPU, ma sullo stesso hardware con RHEL 6 installato utilizzerà circa lo 0,5% della CPU, quindi quando sono in esecuzione da 30 a 50 programmi selectper eseguire una sospensione si consuma un grande quantità di CPU inutilmente.

Ho aperto un Bugzilla e ho provato a eseguire OProfile e mostra semplicemente il 100% in main per l'applicazione e poco più del 99% in poll_idle quando guardo il kernel (ho idle = poll impostato nelle mie opzioni grub in modo che tutto possa essere catturato).

Qualche altra idea di cosa posso fare per cercare di isolare qual è la causa del maggiore utilizzo della CPU?

AGGIORNAMENTO: ho trovato lo strumento perf e ho ottenuto il seguente output:

# 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

Sembra che l'utilizzo della CPU più elevato provenga dallo scheduler. Ho anche usato il seguente script bash per dare il via a 100 di questi contemporaneamente:

#!/bin/bash

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

Su RHEL 5 l'utilizzo della CPU rimane vicino allo 0%, ma su RHEL 6 c'è una quantità non banale di utilizzo della CPU sia in utente che in sistema. Qualche idea su come rintracciare la vera fonte di questo e speriamo di risolverlo?

Ho anche provato questo test su una build Arch Linux corrente e Ubuntu 11.10 e ho visto un comportamento simile, quindi questo sembra essere un tipo di problema del kernel e non solo un problema RHEL.

UPDATE2: esito un po 'a sollevare questo perché so che è un grande dibattito, ma ho provato un kernel con le patch BFS su Ubuntu 11.10 e non mostrava lo stesso utilizzo elevato della CPU del sistema (l'utilizzo della CPU dell'utente sembrava lo stesso).

Esiste un test che posso eseguire con ciascuno di essi per verificare se questo elevato utilizzo della CPU è solo una differenza nella contabilità dell'utilizzo della CPU che la rende artificialmente alta? O se i CFS effettivi vengono rubati dal CFS?

AGGIORNAMENTO3: L'analisi effettuata che coinvolge questa domanda sembra indicare che è qualcosa correlato allo scheduler, quindi ho creato una nuova domanda per discutere i risultati.

UPDATE4: ho aggiunto alcune informazioni in più all'altra domanda .

AGGIORNAMENTO5: Ho aggiunto alcuni risultati all'altra domanda da un test più semplice che dimostra ancora il problema.

Tu chiedi:

Esiste un test che posso eseguire con ciascuno di essi per verificare se questo elevato utilizzo della CPU è solo una differenza nella contabilità dell'utilizzo della CPU che la rende artificialmente alta? O se i CFS effettivi vengono rubati dal CFS?

Cosa succede se si esegue un benchmark della CPU mentre si esegue il test_select_smallprogramma e si vede se le sue prestazioni cambiano a seconda della versione del sistema operativo host?

Ci sono molte scelte: il consiglio classico è sempre "usa qualcosa che rappresenti il ​​tipo di carico che avrai". Ma i ragazzi fighi hanno sempre usato il povray