Différences dans la gestion de l'affinité CPU

Bonjour,

effectuant des benchmarks sur des systèmes linux j'étudie actuellement les différences de comportement du scheduler.
En effet lorsqu'on laisse la gestion de l'affinité à l'OS nous obtiendrons un temps t1, en répétant le même programme mais en lui disant de tourner sur tel ou tel coeur on obtiendra un temps t2.

A savoir que le programme en question (mon bench) fait tourner un main qui est géré par le scheduler ainsi que trois threads qui sont soit gérés par le scheduler soit par moi même, les deux derniers threads effectuent des opérations de synchronisation ou d'envoi de messages (sémaphores nommées, pipe, mémoire partagée, ect).

J'obtiens des écarts de temps catastrophiques entre ces deux essais (t1 < t2), le fait de définir manuellement l'affinité cpu occasionne de sérieux écarts de temps.
Je précise que je tourne sur un ubuntu non patché RT pour mes tests afin d'avoir tous les outils possibles et inimaginables pour étudier le phénomène.

J'ai tenté de forcer les coeurs actifs de la même façon que le choix précédent du scheduler lorsqu'il en avait la charge.
J'ai tenté de forcer sur des coeurs au sein du même CPU (une machine avec deux CPUs de 4 coeurs chacun et une autre avec 1 CPU de 4 coeurs physiques qui virtualise 8 coeurs).

J'ai étudié le déroulement des threads avec LTTng sans observer la moindre différence, hormis pour les temps si "catastrophiques".
J'ai potassé pas mal de documentation, est allé voir dans le code du kernel la partie scheduler mais je n'ai rien trouvé...

Auriez-vous un outil me permettant de mettre en avant le pourquoi ?
Ou bien la doc miraculeuse que j'airai loupé expliquant cela ?

Cordialement,
xTG.

Difficile de te repondre comme ca dans l'absolu, sans comprendre le code ni les besoins de celui-ci, et surtout sans connaitre ton architecture.

Si j'ai bien compris, tu as deux machines a dispo : une mono-CPU, quad-core, hyper-threade, et une bi-CPU quad-core non HT.

Mais quels CPUs ? Comment sont reparties les niveaux de memoire cache ?

Je pense que la perte de perf peut venir de la lorsque tu fais la gestion manuelle : si tu ne mets pas les bons threads sur les bons coeurs, tu as beaucoup plus de defaut de cache que necessaire.

Tu as des outils pour tracer les defauts de cache, ca peut etre une piste a explorer.

Une autre piste, c'est que la gestion manuelle ajoute une surcouche par rapport au scheduler, qui ralentirait tout, mais j'ai un doute.

Je vais me renseigner sur ces outils de défauts de cache. :)

Concernant le programme c'est ainsi :
- main : lance un thread 1
- thread 1 : lance un thread 2 et un thread 3
- thread 2 et thread 3 : ping-pong de wait/post avec des sémaphores nommées

L'architecture de celle ou je favorise mes tests : Intel Xeon 5520 (4 coeurs => 8 threads) - pas trouvé de graphique dans la datasheet pour les caches, je trouve jamais rien de ce que je veux au final dans leurs documents à Intel c'est hallucinant O_o -

J'avais regardé dans /proc/cpuinfo pour cibler les bons coeurs, j'ai même noté le déroulement quand je laissais le scheduler choisir les coeurs que j'ai ensuite appliqué manuellement et comparé les résultats.
C'est pour ça que je ne comprend pas cet écart, je lui demande de faire exactement ce qu'il faisait de façon auto la minute d'avant...

Edit : bon bah cela semble pas provenir des cachemiss...
Ci-après le résultat (mono_mono = fonctionnement forcé sur un coeur, multi_mono = fonctionnement forcé de un thread par coeur, multi_multi = fonctionnement libre)

Citation:

---

======================= mono_mono ==================================

==9904== I refs: 3,979,773
==9904== I1 misses: 4,890
==9904== LLi misses: 3,002
==9904== I1 miss rate: 0.12%
==9904== LLi miss rate: 0.07%
==9904==
==9904== D refs: 1,960,175 (1,313,970 rd + 646,205 wr)
==9904== D1 misses: 13,425 ( 12,012 rd + 1,413 wr)
==9904== LLd misses: 6,377 ( 5,295 rd + 1,082 wr)
==9904== D1 miss rate: 0.6% ( 0.9% + 0.2% )
==9904== LLd miss rate: 0.3% ( 0.4% + 0.1% )
==9904==
==9904== LL refs: 18,315 ( 16,902 rd + 1,413 wr)
==9904== LL misses: 9,379 ( 8,297 rd + 1,082 wr)
==9904== LL miss rate: 0.1% ( 0.1% + 0.1% )

======================= multi_mono ==================================

==9909== I refs: 4,002,179
==9909== I1 misses: 5,003
==9909== LLi misses: 3,036
==9909== I1 miss rate: 0.12%
==9909== LLi miss rate: 0.07%
==9909==
==9909== D refs: 1,972,439 (1,322,202 rd + 650,237 wr)
==9909== D1 misses: 13,521 ( 12,110 rd + 1,411 wr)
==9909== LLd misses: 6,373 ( 5,296 rd + 1,077 wr)
==9909== D1 miss rate: 0.6% ( 0.9% + 0.2% )
==9909== LLd miss rate: 0.3% ( 0.4% + 0.1% )
==9909==
==9909== LL refs: 18,524 ( 17,113 rd + 1,411 wr)
==9909== LL misses: 9,409 ( 8,332 rd + 1,077 wr)
==9909== LL miss rate: 0.1% ( 0.1% + 0.1% )

======================= multi_multi ==================================

==9914== I refs: 4,003,348
==9914== I1 misses: 4,902
==9914== LLi misses: 3,016
==9914== I1 miss rate: 0.12%
==9914== LLi miss rate: 0.07%
==9914==
==9914== D refs: 1,972,537 (1,322,420 rd + 650,117 wr)
==9914== D1 misses: 13,430 ( 12,018 rd + 1,412 wr)
==9914== LLd misses: 6,378 ( 5,296 rd + 1,082 wr)
==9914== D1 miss rate: 0.6% ( 0.9% + 0.2% )
==9914== LLd miss rate: 0.3% ( 0.4% + 0.1% )
==9914==
==9914== LL refs: 18,332 ( 16,920 rd + 1,412 wr)
==9914== LL misses: 9,394 ( 8,312 rd + 1,082 wr)
==9914== LL miss rate: 0.1% ( 0.1% + 0.1% )

---

Sauf erreur de ma part, tu ne mentionnes pas la distribution que tu utilises, ni le noyau - ca pourrait aider.

Quoi qu'il en soit, tu dis avoir regarde les coeurs utilises par le scheduler, mais vu que les threads changent de coeur tres regulierement (sauf configuration particuliere du scheduler), je ne vois pas bien comment tu as pu reproduire cela ?

Sinon, le processeur 5520 que tu cites est en architecture nehalem, avec 4 caches L2, ce qui suppose tres fortement un cache L2 par coeur.

Attention neanmoins, sur les nehalem, les coeurs sont groupes (mais je ne sais plus si c'est par 2 ou par 4, donc je ne sais pas si ca change quelque chose dans ton cas). Cela veut dire par exemple que C0 et C1 sont "proches", de meme que C2 et C3, et passer de l'un a l'autre est rapide, plus que de passer de C1 a C2.
Si le regroupement se fait 4 a 4, cela ne change rien dans ton cas.


Les tests a faire :
Desactiver l'hyper-threading pour voir si ca change quelque chose
Lancer tout sur le meme coeur
Lancer T1 sur un coeur, T2 et T3 sur un second.

Et enfin, j'aimerai comprendre quelque chose : tes tests montrent que le scheduler du noyau est quand meme super efficace, plus que tu ne peux l'etre en te decarcassant (ce qui est logique car tu n'as qu'une connaissance partielle de la machine et du fonctionnement du noyau). Pourquoi dans ce cas vouloir absolument fixer un thread sur un coeur ? Pourquoi ne pas laisser faire le scheduler ? Indice : s'il change les threads de coeur, c'est pas juste pour s'amuser :-)

C'est pas évident du tout de répondre en effet...

typiquement un host quad CPU mono-core, peut potentiellement être bien plus rapide qu'un host mono-processeur 8cores, tout simplement parce que les bus d'entrée/sortie du processeur ou de la ram sont saturés d'informations... pour des miliers de petits traitements.

alors que les même machines comparées sur des dizaines de traitements plus gros ça peut donner l'inverse....

tout dépend de la structure du code, adaptée plus à un cas qu'à l'autre....

après il y a aussi les distinctions cores/threads à prendre en compte ....

mais moins il y a de processeurs physiques, plus il est facile potentiellement de saturer le bus et que tout tes cores y compris l'hyperthreading passe de temps à faire l'instruction NOP "ne rien faire" qui bouffe quand même 2 cycles à chaque fois....

bref il est très difficile de répondre à ta question précisément, mais il tout à fait possible et même logique parfois, qu'un CPU qui à l'air puissant, soit très inadapté à un usage précis.

Pourquoi je m'emmerde ? Parce que je suis stagiaire, que je suis chargé de benchs et que je souhaite donc comprendre ce que fait le scheduler de plus que quand je lui demande la même chose. :P

En effet à me relire il vous manque un bon panier d'informations ! 8O

Alors distribution linux Ubuntu, kernel 3.2.0.
J'avais bien compris la subtilité des caches avec l'architecture nehalem, j'ai donc effectué plusieurs tests. Cela ne change pas les temps, de toute façon c'est la reproduction de l'ordonnancement automatique du scheduler que je reproduis donc au final je m'en fiche.
A savoir que les threads tournent en SCHED_FIFO avec une priorité de 97 (ou de -97 si vous préférez) sur des coeurs inutilisés par l'OS (juste un pauvre kworker qui se balade). Et surtout qu'ils ne changent pas de coeurs durant tout le traitement ! (que cela soit moi qui fixe l'affinité ou bien que cela soit en auto)

Mon problème n'est pas que le scheduler est super efficace, c'est qu'en lui disant de faire ce qu'il doit faire (et qu'il fait de lui même quand on le laisse tranquille) j'obtienne 10% d'écarts de temps.

A noter aussi que je travaille sur deux architectures différents, mais que j'obtiens les mêmes observations sur les deux ! Je teste actuellement sur une troisième (ARM) pour voir si je retrouve le même comportement.

Citation:

---

Envoyé par transgohan

A savoir que les threads tournent en SCHED_FIFO avec une priorité de 97 (ou de -97 si vous préférez) sur des coeurs inutilisés par l'OS (juste un pauvre kworker qui se balade). Et surtout qu'ils ne changent pas de coeurs durant tout le traitement ! (que cela soit moi qui fixe l'affinité ou bien que cela soit en auto)

---

J'ai fait quelques tests (Fedora Core 16, noyau 3.4.4-4 fc16), et il semblerait en effet que le scheduler ne deplace plus les processus entre les processeurs (je n'ai qu'un bi-proc sous la main, pas de multi-coeur). Ce n'est pas le comportement qu'on observait sous Linux il y a quelques temps, d'ou mon discours precedent.

Citation:

---

Mon problème n'est pas que le scheduler est super efficace, c'est qu'en lui disant de faire ce qu'il doit faire (et qu'il fait de lui même quand on le laisse tranquille) j'obtienne 10% d'écarts de temps.

---

Si tu veux comprendre pourquoi, tu n'as plus le choix, il te faut te plonger dans la documentation sur le scheduler, ce qui risque de t'emmener vers les confins de la programmation systeme.
Super interessant si tu aimes ca, mais long et pas trivial.

Plonger dans le code du kernel ne me fait pas peur, j'y regarderai quand j'aurai le temps. :)

Quand je pense qu'à une époque il fallait absolument gérer manuellement l'affinité sous peine de performances catastrophiques... Ce serait quand même ballot que désormais cela soit l'inverse.

Bon bah c'est pas les tests sur l'autre architecture qui m'a apporté lumière...
Même distribution, mais core i5-2410M (1 CPU double coeur multithreadé (4 cpu)).

Et les résultats sont... Aléatoires ! J'avais déjà des écarts certains avec les deux autres architectures mais je ne m'en inquiétais pas sachant que j'étais pas sur du RT mais là...
J'ai des écarts de +20% ou -20% (batterie de 4 tests pour comparer)...
J'ai même des exécutions multicoeurs qui sont 5x plus rapide que l'exécution monocoeur. :aie: (j'ai que des petits appels de bases au kernel dans mes tests et non pas un algo parallélisable, donc c'est impossible d'obtenir ce genre de chiffres)
Bref joli pour ajouter un gros banc de brouillard...
Faudra que je pense à informer mes collègues que la machine qu'ils m'ont prêtés est maudite. :mouarf:

Je pense que tu oublies qu'une machine qui ne fait rien n'existe pas :)

Es-tu seul sur la machine ? Personne d'autre ne peut y acceder pendant tes tests ? Que fait l'OS pendant ce temps la ? Et bien sur, comment fais-tu tes mesures ?

Un resultat acceptable pour un test consiste a le refaire des dizaines de fois, puis a supprimer les 5% les meilleurs et les 5% les pire, et de verifier la variance (elle ne doit pas etre trop elevee). Une fois ce resultat obtenu, tu peux passer au test suivant (meme chose), et ensuite comparer les deux.

Si tu obtiens une variance trop grande, il faut voir si cela peut s'expliquer. Par exemple, un acces disque sur des disques "classiques", c'est a dire non SSD, peuvent etre plus ou moins couteux selon l'algo utilise, et le fait que la donnee soit dans le cache disque ou non.
De meme, l'endormissement d'un processus est un temps minimum garanti, mais pas une borne max. Et ceux-ci dependent bien sur du quantum de temps minimum que tu as sur ta machine (avec un quantum a 20ms, et un sleep de 10ms, j'ai obtenu des resultats d'endormissement entre 20 et 50ms par exemple).

Bref, enormement de parametres rentrent en compte, et il convient d'en analyser un maximum pour voir leurs impacts respectifs et ainsi invalider certaines pistes.

Mon algo n'utilise pas le disque, tout rentre dans le cache L1.
Le L2 (ou L3) n'intervient que pour le dialogue entre deux threads n'étant pas connectés (bref en gros en fonction de l'architecture).
J'utilise bien entendu des machines déconnectées de tout réseau et en effectuant une grosse passe pour dégager le plus d'applications. J'ai d'ailleurs des logs après lancement pour m'indiquer les différentes applications qui ont tournées en même temps comme première approche de comparaison des benchs (j'ai supprimé certains résultats de bench en raison d'applications tournant en parallèle).
Je parlais de 4 tests mais j'en ai lancé davantage, je n'ai juste retenu que ces quatre là. :)

Concernant les mesures je pioche la valeur du tsc.

Quel moyen mettrais-tu en oeuvre pour trouver le quantum de temps d'une machine ? Y-a-t-il un fichier de config y faisant référence ou bien dois-je lancer un test pour le calculer ?