Je ne suis pas tout à fait sûr du travail qui sera effectué par le processeur et de celui qui sera effectué par le système d'exploitation en cas de défaut de page. C'est pourquoi je pose les questions suivantes.
Considérez un processeur monocœur, avec plusieurs processus en cours d'exécution. Lorsqu'une erreur de page se produit, le système d'exploitation essaiera de récupérer la page requise du disque vers la RAM, ce qui coûtera beaucoup de temps. Pendant cette période, le processeur peut-il continuer à s'exécuter? Ou le CPU doit attendre que la page requise soit chargée dans la RAM?
Si le processeur peut continuer à s'exécuter sans attendre la page requise, alors le thrash peut se produire lorsqu'il y a trop de processus. À un moment donné, la plupart des instructions exécutées par le processeur entraîneront des erreurs de page, puis la plupart du temps passé sera à attendre que le système d'exploitation charge les pages du disque vers la RAM. C'est pourquoi la raclée se produit. Puis-je savoir si ma compréhension est correcte?
Merci d'avance.
Mise à jour: ce site Web décrit très bien le thrashing.
3 Réponses :
Dans un système d'exploitation multitâche coopératif, le système d'exploitation ne peut pas initialiser un changement de contexte, le processeur doit donc attendre que la page soit importée.
Les systèmes modernes sontdes systèmes multitâches préventifs . Dans ce cas, le système d'exploitation lancera très probablement un changement de contexte et ainsi d'autres threads / processus s'exécuteront sur le CPU.
Le thrashing est un problème lorsque la quantité de mémoire utilisée dépasse de loin la capacité de la RAM. "Télécharger plus de RAM" est un mème pour une raison.
Pour le thrashing, vous avez mentionné que la quantité de mémoire utilisée dépasse de loin la capacité de la RAM. La mémoire fait-elle ici référence à la mémoire virtuelle?
@EthanL. Oui___
Le CPU peut continuer à s'exécuter.
La CPU ne peut cependant pas poursuivre l'exécution du thread qui a causé la faute. Ce thread a besoin que l'erreur soit résolue avant que l'instruction suivante puisse être exécutée. Autrement dit, il doit bloquer sur la faute.
Le fait que de nombreux threads / processus puissent être bloqués lors de la gestion des pannes n'est pas en soi un problème. Le thrashing se produit lorsque, pour insérer une page, il n'y a pas suffisamment de cadres de page libres, il est donc nécessaire d'écrire une page. Mais ensuite, lorsque le système d'exploitation tente de trouver un autre thread à exécuter, il sélectionne le thread qui possédait une page qu'il vient d'écrire, il doit donc renvoyer cette page en faute.
Le thrashing est donc un symptôme d'une mémoire réelle disponible insuffisante.
Le processeur ne sait pas qu'il est "dans" une erreur de page. Les processeurs ne sont pas récursifs !
Lorsqu'un processeur x86 32 bits (par exemple) rencontre une erreur de page, voici ce qu'il fait (légèrement simplifié):
C'est tout ce qu'il fait. Maintenant, il y a des données sur la pile que le noyau utilise quand il veut que le CPU revienne à ce qu'il faisait avant que l'erreur de page ne se produise. Mais le noyau n'est pas obligé d'utiliser ces données. Il pourrait retourner quelque part complètement différent, ou il ne pourrait jamais revenir en arrière. Cela dépend du noyau. Le CPU s'en fiche.
Un noyau habituel va d'abord enregistrer tous les autres registres (important!), Regarder l'adresse, décider où obtenir la page, dire au disque de commencer à récupérer la page, noter que le processus est arrêté à cause d'un défaut de page, puis il ira et fera quelque chose d'entièrement différent jusqu'à ce que les données reviennent du disque. Il peut exécuter un processus différent, par exemple. S'il n'y a plus de processus à exécuter, cela peut désactiver le processeur (oui, vraiment).
Finalement, les données reviennent du disque et le noyau voit qu'il y a un processus en attente de ces données en raison d'une erreur de page, et il met à jour la table de page afin que le processus puisse voir les données, et il réinitialise tous les registres, y compris SS, ESP, EFLAGS, CS et EIP. Maintenant, le CPU fait tout ce qu'il faisait auparavant.
Le point clé à noter est: le processeur ne se soucie que de ce qui est dans ses registres pour le moment ! Il n'a pas de mémoire à long terme. Si vous sauvegardez les valeurs du registre quelque part, vous pouvez l'empêcher de faire ce qu'il faisait et le reprendre plus tard comme si de rien n'était. Par exemple, il n'est absolument pas nécessaire de retourner les appels de fonction dans l'ordre dans lequel ils se sont produits. Le CPU ne se soucie pas si vous avez une fonction qui retourne deux fois, par exemple (voir setjmp ), ou si vous avez deux coroutines et que l'appel de yield dans une coroutine provoque le retour de yield dans l'autre. Vous n'avez pas à faire les choses dans l'ordre de la pile comme vous le faites en C.