Aller plus loin
- "RunTime" (24 clics)
"RunTime" : changement de contexte, Première partie
25
sept.
2002
Cet article mesure les dépassements impliqués par le changement de contexte. On y trouve une démonstration de changement de contexte puis une opportunité à mesurer la vitesse d'une opération de changement de contexte. (Contient des exemples de code)
# correction please
Posté par Olivier Jeannet . Évalué à 8.
Cette phrase ne veut pas dire grand chose en français. On ne dit pas "une opportunité" de toutes façons, la traduction de l'anglais "an opportunity" est "une occasion" ou "une possibilité". On parle de l'opportunité d'une décision ou d'un acte, le mot s'emploie comme pour la "pertinence".
Il faut traduire la phrase en anglais par :
"puis la [simple] possibilité de mesurer la vitesse"
(pour la traduction exacte du "simple" de la phrase ça n'est pas évident d'ailleurs).
# humpf
Posté par Vivi (site web personnel) . Évalué à 5.
[^] # Re: humpf
Posté par reno . Évalué à -1.
[^] # Re: humpf
Posté par Gniarf . Évalué à 2.
[^] # Forçément dès qu'il s'agit de réfléchir au lieu de "troller" sur Micro
Posté par _ _ . Évalué à 4.
Pourtant, récemment un article sur le support des threads Posix sous Linux, donc le même sujet, avait déchaîné une avalanche de commentaires. Cet article contient au fait énormément d'informations, beaucoup plus que la news sus-citée, simplement il faut un peu de compétence technique pour les trouver.
Par exemple, la complexité d'un scheduler(ordonnanceur) c'est la pente de la courbe :
Y = durée du changement de contexte / X = nbre de tâches.
Sur le graphique en fonction du nbre de thread, on voit que la courbe de Linux 2.4 est nettement plus pentue que les courbes de 2000/XP, et de plus la courbe lissée de Linux semble arrondie (donc pire que O(n)) alors que celle de NT semble plutôt constituée de deux segments de droites (du O(n) ou O(log n) peut être ?).
Celà signifie que la complexité du scheduler du kernel 2.4 est plus mauvaise que celle de NT, d'ou une plus mauvaise montée en charge, c'est ce graphique qui explique pourquoi Ingo Molinar à chercher à l'améliorer avec son fameux "patch O(1)". Patch qui d'ailleurs avait été au début refusé par Linus suivant une argumentation que Ingo avait resumé en "les vrai hommes font de la VM, le scheduler on s'en tape".
On peut penser, que si la complexité du scheduler cause des problèmes de montée en charge qui rendent Linux inutilisable sur certaines applications, RedHat & co ont du faire pression sur Linus pour le ramener à la raison !
Bon j'arrête là ce commentaire car il est l'heure d'aller me coucher, mais il y aurait d'autres choses à dire : par exemple sur le nombre maximum de 128 threads que supporte la RedHat à comparer aux nombre de threads max sous NT qui est bien plus élévé, ou bien sur le fait que si Linux s'en tire effectivement mieux pour scheduler les processus que NT (un facteur 6) grâce son modèle "toute tâche est vue comme un processus", celà pénalise les performances en commutation de threads d'un facteur 2 environ, ce qui me fait douter du choix de Linus de refuser d'implémenter le concept de thread au niveau du noyau (sa fameuse architecture du system call unique clone()")
# Si le sujet vous intéresse...
Posté par Gaël Le Mignot . Évalué à 10.
Ensuite, si vous voulez vous tenir au courant des dernières avancées de la recherche en OSDev pour réduire le coût des changements de contexte, il existe de très bon articles là-dessus faits par l'épique de L4Ka: http://www.l4ka.org/publications/(...) en particulier: Performance of Address-Space Multiplexing on the Pentium, Lazy Process Switching, Improved Address-Space Switching on Pentium Processors by Transparently Multiplexing User Address Spaces et Lazy Context Switching Algorithms for Sparc-like Processors (les autres sont très intéressant aussi).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.