Isoler la cause d'une utilisation plus élevée du processeur sur RHEL 6 vs RHEL 5

Je cherche actuellement à déplacer notre système de RHEL 5 à RHEL 6, mais j'ai rencontré un problème avec une utilisation CPU étonnamment élevée sur les machines RHEL 6. Il semble que cela puisse être dû au moins en partie à l'utilisation de selectpour faire un sommeil interruptible. Voici un exemple simple qui montre le comportement:

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

Sur une machine RHEL 5, il restera à 0% d'utilisation du processeur, mais sur le même matériel avec RHEL 6 installé, il utilisera environ 0,5% du processeur, donc lorsque 30 à 50 programmes sont en cours selectd'exécution pour effectuer une mise en veille, il mange un une grande quantité de CPU inutilement.

J'ai ouvert un Bugzilla et j'ai essayé d'exécuter OProfile et il montre simplement 100% en principal pour l'application et un peu plus de 99% dans poll_idle en regardant le noyau (j'ai idle = poll défini dans mes options grub pour que tout puisse être capturé).

Avez-vous d'autres idées sur ce que je peux faire pour essayer d'isoler la cause de l'utilisation plus élevée du processeur?

MISE À JOUR: J'ai trouvé l'outil perf et obtenu la sortie suivante:

# 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

Il semble que l'utilisation la plus élevée du processeur provient du planificateur. J'ai également utilisé le script bash suivant pour lancer 100 d'entre eux simultanément:

#!/bin/bash

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

Sur RHEL 5, l'utilisation du processeur reste proche de 0%, mais sur RHEL 6, il y a une quantité non négligeable d'utilisation du processeur à la fois par l'utilisateur et par le système. Avez-vous des idées sur la façon de trouver la véritable source de cela et, espérons-le, de le corriger?

J'ai également essayé ce test sur une version Arch Linux actuelle et Ubuntu 11.10 et j'ai vu un comportement similaire, donc cela semble être un certain type de problème de noyau et pas seulement un problème RHEL.

UPDATE2: J'hésite un peu à en parler car je sais que c'est un débat énorme, mais j'ai essayé un noyau avec les correctifs BFS sur Ubuntu 11.10 et il ne montrait pas la même utilisation élevée du CPU du système (l'utilisation du processeur utilisateur semblait le même).

Existe-t-il un test que je peux exécuter avec chacun d'eux pour tester si cette utilisation élevée du processeur n'est qu'une différence dans la comptabilisation de l'utilisation du processeur qui la rend artificiellement élevée? Ou si des cycles CPU réels sont volés par le CFS?

UPDATE3: L'analyse effectuée impliquant cette question semble indiquer que c'est quelque chose lié au planificateur, j'ai donc créé une nouvelle question pour discuter des résultats.

UPDATE4: J'ai ajouté quelques informations supplémentaires à l' autre question .

UPDATE5: J'ai ajouté quelques résultats à l' autre question à partir d'un test plus simple qui démontre toujours le problème.

Tu demandes:

Existe-t-il un test que je peux exécuter avec chacun d'eux pour tester si cette utilisation élevée du processeur n'est qu'une différence dans la comptabilisation de l'utilisation du processeur qui la rend artificiellement élevée? Ou si des cycles CPU réels sont volés par le CFS?

Que se passe-t-il si vous exécutez un benchmark CPU pendant que vous exécutez votre test_select_smallprogramme et voyez si ses performances changent en fonction de la version du système d'exploitation hôte?

Il y a beaucoup de choix: le conseil classique est toujours "utilisez quelque chose qui représente le type de charge que vous aurez". Mais les enfants cool ont toujours utilisé povray