Contexte de fil de commutation Vs. changement de contexte de processus
Quelqu'un pourrait-il me dire ce qui se passe exactement dans les deux situations? Quel est le coût principal de chacun d'eux?
La principale différence entre un commutateur de processus et un commutateur de processus est que, lors d’un changement de thread, l’espace mémoire virtuelle reste le même, alors qu’il ne le fait pas pendant un commutateur de processus . effectuer le changement de contexte. Le processus d’entrée et de sortie du noyau du système d’exploitation, associé au coût de la commutation des registres, représente le coût fixe le plus élevé pour effectuer un changement de contexte.
Un coût plus flou réside dans le fait qu'un commutateur de contexte désorganise les mécanismes de mise en cache des processeurs. Fondamentalement, lorsque vous changez de contexte, toutes les adresses de mémoire que le processeur "se souvient" dans son cache deviennent inutilisables. La grande différence est que lorsque vous modifiez des espaces de mémoire virtuelle, le tampon de traduction, ou son équivalent, est vidé, ce qui rend les accès mémoire beaucoup plus coûteux pendant un certain temps. Cela ne se produit pas lors d'un changement de thread.
La commutation du contexte de processus implique la commutation de l'espace d'adressage mémoire. Cela inclut les adresses de mémoire, les mappages, les tables de pages et les ressources du noyau, une opération relativement coûteuse. Sur certaines architectures, cela signifie même le vidage de plusieurs caches de processeurs qui ne peuvent pas être partagés entre espaces d'adresses. Par exemple, x86 doit vider le TLB et certains processeurs ARM doivent vider la totalité du cache L1!
La commutation de threads est une commutation de contexte d'un thread à un autre dans le même processus (la commutation d'un processus à l'autre n'est qu'un processus). Le changement d'état d'un processeur (tel que le contenu du programme et du registre) est généralement très efficace.
Tout d’abord, le système d’exploitation met les threads sortants en mode noyau s’ils ne le sont pas déjà, car les commutateurs de threads ne peuvent être exécutés qu’entre threads et s’exécutant en mode noyau. Ensuite, le planificateur est appelé pour prendre une décision concernant le fil sur lequel le basculement sera effectué. Une fois la décision prise, le noyau enregistre une partie du contexte de thread situé dans la CPU (registres de la CPU) dans l'emplacement dédié en mémoire (souvent au sommet de la pile de threads sortante du noyau). Ensuite, le noyau effectue le basculement de la pile de noyau du thread sortant vers la pile de noyau du thread entrant. Après cela, le noyau charge le contexte précédemment stocké du thread entrant à partir de la mémoire dans les registres de la CPU. Et retourne enfin le contrôle en mode utilisateur, mais en mode utilisateur du nouveau thread. Dans le cas où le système d'exploitation a déterminé que le thread entrant s'exécute dans le processus another, le noyau effectue une étape supplémentaire: définit le nouvel espace d'adressage virtuel actif.
Le coût principal dans les deux scénarios est lié à une pollution de cache. Dans la plupart des cas, le jeu de travail utilisé par le thread sortant diffère considérablement du jeu de travail utilisé par le thread entrant. En conséquence, le thread entrant commencera sa vie avec une avalanche de données manquantes dans le cache, éliminant ainsi les anciennes données inutiles des caches et chargeant les nouvelles données de la mémoire. La même chose est vraie pour le TLB (Translation Look-Side Buffer, qui se trouve sur la CPU). Dans le cas de la réinitialisation de l'espace d'adressage virtuel (les threads s'exécutant dans différents processus), la pénalité est encore pire, car la réinitialisation de l'espace d'adressage virtuel entraîne le vidage de l'intégralité du TLB, même si le nouveau thread doit être chargé uniquement quelques nouvelles entrées. En conséquence, le nouveau thread commencera son heure avec beaucoup de ratés TLB et de pages fréquentes. Le coût direct du changement de threads n’est pas non plus négligeable (de-250 à 1500-2000 cycles) et dépend de la complexité du processeur, des états des threads et des jeux de registres qu’ils utilisent réellement.
P.S .: Bon article sur la surcharge de contexte: http://blog.tsunanet.net/2010/11/how-long-does-it-take-take-make-context.html
- commutation de processus: / il s'agit d'une transition entre deux mémoires résidant dans un processus dans un environnement multiprogrammé;
- commutation de contexte: il s'agit d'un contexte changeant d'un programme en cours d'exécution à une routine de service d'interruption (ISR).
Dans Thread Context Switching, l’espace mémoire virtuel reste le même alors que ce n’est pas le cas dans Process Context Switch. En outre, Process Context Switch est plus coûteux que Thread Context Switch.
Bien que la commutation de contexte de thread ait besoin de changer le contexte d'exécution (registres, pointeurs de pile, compteurs de programme), ils n'ont pas besoin de changer d'espace d'adressage comme le font les commutateurs de contexte. Il y a un coût supplémentaire lorsque vous changez d'espace d'adressage, plus d'accès à la mémoire (pagination, segmentation, etc.) et vous devez vider le TLB lors de l'entrée ou de la sortie d'un nouveau processus ...
Je pense que la différence principale réside dans l'appel de switch_mm(), qui gère les descripteurs de mémoire des tâches anciennes et nouvelles. Dans le cas des threads, l'espace d'adressage de la mémoire virtuelle est inchangé (les threads partagent la mémoire virtuelle), il reste donc très peu à faire et donc moins coûteux.