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()")
[^] # Forçément dès qu'il s'agit de réfléchir au lieu de "troller" sur Micro
Posté par _ _ . En réponse à la dépêche "RunTime" : changement de contexte, Première partie. É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()")