Isolando a causa do maior uso da CPU no RHEL 6 vs RHEL 5

Atualmente, estou procurando mudar nosso sistema do RHEL 5 para o RHEL 6, mas me deparei com um problema inesperadamente alto no uso da CPU nas máquinas RHEL 6. Parece que isso pode dever-se, pelo menos em parte, ao uso de selectum sono interrompido. Aqui está um exemplo simples que mostra o 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;
}

Em uma máquina RHEL 5, ele permanecerá com 0% de uso da CPU, mas no mesmo hardware com o RHEL 6 instalado, ele usará cerca de 0,5% da CPU; portanto, quando 30 a 50 programas estiverem sendo executados usando-os selectpara realizar um sono, ele consome um grande quantidade de CPU desnecessariamente.

Abri um Bugzilla e tentei executar o OProfile e ele simplesmente mostra 100% no principal do aplicativo e pouco mais de 99% no poll_idle ao olhar para o kernel (eu tenho idle = poll definido nas minhas opções de grub para que tudo possa ser capturado).

Alguma outra idéia do que posso fazer para tentar isolar qual é a causa do maior uso da CPU?

UPDATE: Encontrei a ferramenta perf e obtive a seguinte saída:

# 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

Parece que o maior uso da CPU é do agendador. Também usei o seguinte script bash para iniciar 100 deles simultaneamente:

#!/bin/bash

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

No RHEL 5, o uso da CPU permanece próximo de 0%, mas no RHEL 6 há uma quantidade não trivial de uso da CPU no usuário e no sistema. Alguma idéia de como rastrear a verdadeira fonte disso e, esperamos, corrigi-lo?

Eu também tentei esse teste em uma versão atual do Arch Linux e no Ubuntu 11.10 e vi um comportamento semelhante; portanto, isso parece ser algum tipo de problema no kernel e não apenas um problema no RHEL.

UPDATE2: Hesito um pouco em trazer isso à tona porque sei que é um grande debate, mas experimentei um kernel com os patches BFS no Ubuntu 11.10 e ele não mostrou o mesmo alto uso da CPU do sistema (o uso da CPU do usuário parecia o mesmo).

Existe algum teste que eu possa executar com cada um deles para testar se esse alto uso da CPU é apenas uma diferença na contabilidade do uso da CPU que está fazendo com que pareça artificialmente alto? Ou se os ciclos reais da CPU estão sendo roubados pelo CFS?

ATUALIZAÇÃO3: A análise feita com esta pergunta parece indicar que é algo relacionado ao agendador, por isso criei uma nova pergunta para discutir os resultados.

UPDATE4: Adicionei mais algumas informações à outra pergunta .

UPDATE5: adicionei alguns resultados à outra pergunta de um teste mais simples que ainda demonstra o problema.

Você pergunta:

Existe algum teste que eu possa executar com cada um deles para testar se esse alto uso da CPU é apenas uma diferença na contabilidade do uso da CPU que está fazendo com que pareça artificialmente alto? Ou se os ciclos reais da CPU estão sendo roubados pelo CFS?

E se você executasse um benchmark de CPU enquanto executava o test_select_smallprograma e veja se o desempenho muda dependendo da versão do sistema operacional host?

Existem muitas opções: o conselho clássico é sempre "use algo que represente o tipo de carga que você terá". Mas as crianças legais sempre usavam povray