Cause d'isolement de l'utilisation du processeur supérieure 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 inattendue élevée sur les machines RHEL 6. Il semble que cela peut être due au less dans une partie à l'utilisation de select pour faire un sumil 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 restra à 0% de l'utilisation du processeur, mais sur le même matériel avec RHEL 6 installé, il utilisera environ 0,5% de la CPU, donc quand 30 à 50 programmes sont en cours d'exécution en select pour dormir une grande quantité du CPU inutilement.

J'ai ouvert un Bugzilla et j'ai essayé d'exécuter OProfile et il affiche simplement 100% en principal pour l'application et un peu plus de 99% dans poll_idle en regardant le kernel.

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

UPDATE: J'ai trouvé l'outil perf et j'ai 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 supérieure du processeur provient du planificateur. J'ai aussi utilisé le script bash suivant pour en lancer 100 simultanément:

 #!/bin/bash for i in {1..100} do ./test_select_small & done 

Sur RHEL 5, l'utilisation du processeur rest proche de 0%, mais sur RHEL 6, l'utilisation du processeur est non négligeable tant pour l'user que pour le système. Toutes les idées sur la façon de traquer la véritable source de cela et, espérons-le résoudre?

J'ai également essayé ce test sur une version actuelle d'Arch Linux et Ubuntu 11.10 et j'ai vu un comportement similaire. Il semble donc qu'il s'agisse d'un problème de kernel et non d'un problème RHEL.

UPDATE2: J'hésite un peu à en parler parce que je sais que c'est un énorme débat, mais j'ai testé un kernel avec les patchs BFS sur Ubuntu 11.10 et il n'affichait pas la même utilisation élevée du CPU du système le même).

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

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

UPDATE4: J'ai ajouté plus d'informations à l' autre question .

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

Tu requests:

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

Que se passe-t-il si vous avez exécuté un benchmark CPU pendant que vous exécutez votre programme test_select_small et voyez si ses performances changent en fonction de la version du operating system hôte?

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