Bonsoir

j'ai quelques questions.

Par avance merci pour votre aide.

Pourriez-vous m'aider à comprendre chaque idée du passage suivant :

"Ces changements de contexte pèsent sur la gestion des threads par le système et peuvent se révéler particulièrement coûteux lorsque le thread matériel attribué à un thread logiciel se trouve sur un coeur différent de celui utilisé lors de l'intervalle de temps précédent accordé au même thread logiciel. Dans ce cas, (1) les caches du processeur pour ce thread logiciel sont en général invalides (ils contiennent peu de données et quelques instructions utiles) et (2) l'exécution du "nouveau" thread logiciel sur ce coeur pollue les caches du processeur associés aux "anciens" threads qui ont été exécutés sur ce coeur et qui risquent fort de l'être à nouveau lors de l'intervalle de temps suivant.

Mes questions :

1) pour quelle raison le thread matrériel attribué à un thread logiciel pourrait se trouver sur un coeur différent de celui utilisé lors de l'intevelle de teps précédent ?

2) Que veut-on dire par "les caches du processeur pour ce thread logiciel sont en général invalides"  ?

3) Que veut-on dire par " ils contiennent peu de données et quelques instructions utiles " ?

4) Que veut-on dire par " l'exécution du nouveau thread logiciel sur ce coeur pollue les caches du processeur associés aux "anciens" threads qui ont été exécutés sur ce coeur et qui risquent fort de l'être à nouveau lors de l'intervalle de temps suivant." ?

Merci beaucoup pour votre aide

-
Edité par pseudo-simple 9 juin 2019 à 20:38:03

Salut, ta phrase commence par "ces changements", il nous manque tout ce qu'il y a avant, le contexte et tout. J'imagine qu'il y a tout un cheminement dans ton livre...

Salut, voici ce qui est avant , si tu peux m'aider à comprendre mon premier message :

"Même si nous ne sommes pas à court de threads, nous pouvons rencontrer des problèmes en raison d'une demande excédentaire. Cela se produit lorsque le nombre de threads logiciels prêts à s'exécuter (non bloqués) est supérieur au nombre de threads  matériels. Dans ce cas, le gestionnaire des threads (qui fait en général partie du système d'exploitation) accorde des intervalles  de teps matériel aux threads logiciels. Lorsque l'intervalle de temps d'un thread est terminé et qu'un autre débute, un changement de contexte est réalisé."

Puis vient le passage de mon premier message.

D'ailleurs, j'ai un nouvelle question : que se passe-t-il techniquement lors d'un "changement de contexte"   ?

En vous remerciant par avance

-
Edité par pseudo-simple 10 juin 2019 à 11:43:14

Bonjour,

Il doit y avoir avant des explications sur ce qu'est la mémoire cache. Tu devrais les relire.
1)
Et pourquoi pas? Tout noyau qui se respecte n'a aucune raison de changer spontanément un thread logiciel de processeur. Mais s'il y a plus de threads logiciels demandeurs, le noyau va après un certain temps préempter un threads. Plus tard, quand un des processeurs est libre, le thread logiciel sera remis en route. Rien ne dit que ça se fera sur le même processeur.

2)
Un cache invalide correspond à un cache qui ne contient pratiquement plus de données qui sont synchrones avec la mémoire. Conséquence : toutes les actions qui se feront (exécution d'instruction, lecture de mémoire, ...) seront fortement ralenties car accéder à la mémoire est nettement plus lent pour les choses qui ne sont pas dans le cache.

3)
cf 2)

4)
Au moment du basculement de contexte. Le cache contient des données rapides correspondant à ce que faisait le thread précédent. Le nouveau thread fait une tout autre chose, ses accès seront donc très différents et il n'y peu de choses intéressantes dans le cache. Le nouveau devra donc faire des accès lent en RAM pendant que petit à petit le cache se synchronisera avec ces données. Tout ça pour se faire "piquer" le CPU donc aussi le cache au après.

5)
Un changement de contexte c'est : changer d'état processeur (ce qui correspond en gros à tous les registres du processeur à sauvegarder/restaurer y compris un changement de pile) et peut-être aussi de changer de processeur (et donc souvent de cache associé). 

Pourquoi le thread matériel peut changer. C'est juste une question de bon sens... Comment l'ordonnanceur pourrait deviner que peut être dans les 500 prochaines millisecondes le thread de ton appli obtiendra un time slice... Pas évident...  Et si je bloque un thread matériel, juste au cas où, je vais rapidement avoir un gros souci, parce qu'en gros, 1 thread matériel = 1 coeur de processeur. Si tu regardes le nombre de processus qui tournent, le compte n'y est pas.

Bonjour  Daflab et int21h FVirtman ,

@int21h : apparemment on ne peut pas faire l'assertion que tu suggères (à savoir que en gros 1 thread matériel = 1 coeur)

Un coeur serait composé de nombreux threads matériels. 

@Daflab : merci pour tes explications détaillées. cela me paraît un peu plus clair maintenant.

-
Edité par pseudo-simple 10 juin 2019 à 16:28:48

Bien sûr que si tu peux la faire. Le nombre de thread matériel par coeur est limité, que tu puisses en avoir un ou 100 ne change rien sur le fond, il y en aura toujours beaucoup moins que des thread logiciels...

Je te comprends si tu te places du point de vue de la complexité (asymptotiquement)

OK

-
Edité par pseudo-simple 10 juin 2019 à 17:21:39

int21h a écrit:

Bien sûr que si tu peux la faire. Le nombre de thread matériel par coeur est limité, que tu puisses en avoir un ou 100 ne change rien sur le fond, il y en aura toujours beaucoup moins que des thread logiciels...

Pour votre info, avez-vous entendu parler de ça! (256 cœurs, sur une puce!).

Juste pour leur faire un peu de pub, ils sont français!