Pour ma part, je pense aussi que ça donne la possibilité d'activer dynamiquement le kernel tracing (désolé pour le "franglicisme").
En revanche, je ne suis pas trop d'accord avec : si (unlikely(point_de_tracing_activé))
alors vrai_travail_de_tracing;
sinon ne_rien_faire De cette façon les noyaux normaux qui n'activent pas le tracing, et qui sont l'immense majorité, ne patissent pas du coût des opérations...à l'exception du petit test initial !
car, pour ce que j'en comprend, le branchement prédictif se fait sur si (condition)
alors ...
Le code présenté serait donc optimisé pour le cas où le tracing est activé.
Dans le cas contraire, le branchement prédictif est erroné et le contexte CPU doit être rechargé.
Quelqu'un pourrait confirmer ?
De même, je m'interroge sur le bénéfice du saut/jump (qui est une rupture de contexte puisqu'il introduit une discontinuité dans la séquence des instructions) à moins que les processeurs actuels soient en mesure d'"anticiper" un saut (i.e. précharger le contexte en tenant compte du saut) ou que le pipeline d'instructions soit suffisamment court pour ne pas être impacté. (impensable sur les générations Intel P3/P4).
Du coup, j'ai du mal à comprendre comment les performances ont pu être améliorées avec :
Le premier test se fait en idle (c'est à dire avec une machine inoccupée).
Avant le patch : 32 cycles
Après le patch : 2 cycles
Le second test s'effectue après avoir lancé le test tbench pour générer de l'activité sur la machine.
Avant le patch : 88 cycles
Après le patch : 4 cycles
Si là encore quelqu'un peut éclairer ma lanterne :)
[^] # Re: Traçage et performances
Posté par Quzqo . En réponse à la dépêche Sortie de la version 2.6.37 du noyau Linux. Évalué à 4.
En revanche, je ne suis pas trop d'accord avec :
si (unlikely(point_de_tracing_activé))alors vrai_travail_de_tracing;
sinon ne_rien_faire
De cette façon les noyaux normaux qui n'activent pas le tracing, et qui sont l'immense majorité, ne patissent pas du coût des opérations...à l'exception du petit test initial !
car, pour ce que j'en comprend, le branchement prédictif se fait sur
si (condition)alors ...
Le code présenté serait donc optimisé pour le cas où le tracing est activé.
Dans le cas contraire, le branchement prédictif est erroné et le contexte CPU doit être rechargé.
Quelqu'un pourrait confirmer ?
De même, je m'interroge sur le bénéfice du saut/jump (qui est une rupture de contexte puisqu'il introduit une discontinuité dans la séquence des instructions) à moins que les processeurs actuels soient en mesure d'"anticiper" un saut (i.e. précharger le contexte en tenant compte du saut) ou que le pipeline d'instructions soit suffisamment court pour ne pas être impacté. (impensable sur les générations Intel P3/P4).
Du coup, j'ai du mal à comprendre comment les performances ont pu être améliorées avec :
Le premier test se fait en idle (c'est à dire avec une machine inoccupée).
Avant le patch : 32 cycles
Après le patch : 2 cycles
Le second test s'effectue après avoir lancé le test tbench pour générer de l'activité sur la machine.
Avant le patch : 88 cycles
Après le patch : 4 cycles
Si là encore quelqu'un peut éclairer ma lanterne :)