Pour faire une réponse plus intelligente que le gros malin ci-dessus, ça permet de corriger un GROS problème des P4 3.0 C.
C'est vu comme un bi proc mais certaines unités de calcul et le cache sont partagés entre les 2 unités, ce qui en pratique veut dire que, contrairement à un vrai bipro, une appli qui tourne sur un des CPU peut effondrer les performances de celui qui tourne sur l'autre.
Si toutes les taches avaient la même priorité, ça ne serait pas un problème vu que le P4 les ferait tourner du mieux qu'il peut, c'est à dire 1.1 à 1.2 fois plus vite que le même CPU tournant sans l'hyperthreading. (on ne gagne pas plus en activant l'HT mais c'est toujours ça de pris quand ça marche).
Sauf que quand les priorités sont très différentes (genre Seti@Home en nice 19 et une tache sur le bureau en priorité 0) entre 2 taches en train de tourner, ça se passe très mal.
Sur un monopro classique, la tache en nice 19 ne tourne quasiment plus quand une tache doit tourner en priorité 0.
Sur un bipro, les 2 tournent à fond et c'est pas bien grâve.
Sur un P4 HT, vu comme un bipro normal par Linux, il fait tourner les 2 taches à fond (toujours logique) et du coup la tache en priorité 0 se retrouve ralentie quasiment de moitié !
Le but des patchs de Con Kolivas est de rendre le scheduler conscient de ce cas de figure en empéchant de tourner les taches de priorité inférieure sur l'autre CPU quand une tache de priorité supérieur à besoin de tourner.
Bon, évidement, il n'y a pas que ça dans le patch CK.
Pour la version en VO et expliquée plus clairement :
[^] # Re: -mm... et -ck !
Posté par Serge Rossi (site web personnel) . En réponse à la dépêche Noyau 2.6.3 dans les bacs. Évalué à 9.
C'est vu comme un bi proc mais certaines unités de calcul et le cache sont partagés entre les 2 unités, ce qui en pratique veut dire que, contrairement à un vrai bipro, une appli qui tourne sur un des CPU peut effondrer les performances de celui qui tourne sur l'autre.
Si toutes les taches avaient la même priorité, ça ne serait pas un problème vu que le P4 les ferait tourner du mieux qu'il peut, c'est à dire 1.1 à 1.2 fois plus vite que le même CPU tournant sans l'hyperthreading. (on ne gagne pas plus en activant l'HT mais c'est toujours ça de pris quand ça marche).
Sauf que quand les priorités sont très différentes (genre Seti@Home en nice 19 et une tache sur le bureau en priorité 0) entre 2 taches en train de tourner, ça se passe très mal.
Sur un monopro classique, la tache en nice 19 ne tourne quasiment plus quand une tache doit tourner en priorité 0.
Sur un bipro, les 2 tournent à fond et c'est pas bien grâve.
Sur un P4 HT, vu comme un bipro normal par Linux, il fait tourner les 2 taches à fond (toujours logique) et du coup la tache en priorité 0 se retrouve ralentie quasiment de moitié !
Le but des patchs de Con Kolivas est de rendre le scheduler conscient de ce cas de figure en empéchant de tourner les taches de priorité inférieure sur l'autre CPU quand une tache de priorité supérieur à besoin de tourner.
Bon, évidement, il n'y a pas que ça dans le patch CK.
Pour la version en VO et expliquée plus clairement :
http://members.optusnet.com.au/ckolivas/kernel/(...)