Quelles sont les différences entre la mémoire virtuelle et la mémoire physique ?

Question

Je suis souvent dérouté par le concept de virtualisation dans les systèmes d'exploitation. Si l'on considère la RAM comme la mémoire physique, pourquoi avons-nous besoin de la mémoire virtuelle pour exécuter un processus ?

Où en est cette mémoire virtuelle lorsque le processus (programme) du disque dur externe est amené dans la mémoire principale (mémoire physique) pour l'exécution.

Qui s'occupe de la mémoire virtuelle et quelle est la taille de la mémoire virtuelle ?

Supposons que la taille de la RAM soit de 4 Go (soit 2^32-1 espaces d'adressage), quelle est la taille de la mémoire virtuelle ?

Answer 1

Les logiciels fonctionnent sur le système d'exploitation selon un principe très simple : ils ont besoin de mémoire. Le système d'exploitation du périphérique la fournit sous la forme de mémoire vive. La quantité de mémoire requise peut varier - certains logiciels ont besoin d'une mémoire énorme, d'autres d'une mémoire dérisoire. La plupart des utilisateurs (si ce n'est tous) exécutent simultanément plusieurs applications sur le système d'exploitation et, étant donné que la mémoire est chère (et que la taille des appareils est limitée), la quantité de mémoire disponible est toujours limitée. Ainsi, étant donné que tous les logiciels ont besoin d'une certaine quantité de RAM et qu'ils peuvent tous être exécutés en même temps, le système d'exploitation doit s'occuper de deux choses :

1. Que le logiciel siempre s'exécute jusqu'à ce que l'utilisateur l'interrompe, c'est-à-dire qu'elle ne doit pas s'interrompre automatiquement parce que le système d'exploitation manque de mémoire.
2. L'activité ci-dessus, tout en maintenant une performance respectable pour les logiciels en cours d'exécution.

La question principale se résume maintenant à la manière dont la mémoire est gérée. Qu'est-ce qui régit exactement l'emplacement dans la mémoire des données appartenant à un logiciel donné ?

Solution possible 1 : Laissez les logiciels individuels spécifier explicitement l'adresse mémoire qu'ils utiliseront dans le dispositif. Supposons que Photoshop déclare qu'il utilisera toujours les adresses mémoire comprises entre 0 à 1023 (imaginez la mémoire comme un tableau linéaire d'octets, donc le premier octet est à la position 0 , 1024 e octet est à l'emplacement 1023 ) - c'est-à-dire en occupant 1 GB mémoire. De même, VLC déclare qu'il occupera la plage de mémoire 1244 à 1876 etc.

Avantages :

1. Chaque application se voit attribuer au préalable un emplacement de mémoire. Ainsi, lorsqu'elle est installée et exécutée, elle stocke ses données dans cette zone de mémoire et tout fonctionne bien.

Inconvénients :

1. Cela n'a pas d'échelle. En théorie, une application peut avoir besoin d'une énorme quantité de mémoire lorsqu'elle effectue une tâche très lourde. Pour qu'elle ne soit jamais à court de mémoire, la zone de mémoire qui lui est allouée doit donc toujours être supérieure ou égale à cette quantité de mémoire. Que se passe-t-il si un logiciel, dont l'utilisation maximale théorique de la mémoire est de 2 GB (nécessitant donc 2 GB allocation de mémoire à partir de la RAM), est installé dans une machine avec seulement 1 GB la mémoire ? Le logiciel devrait-il simplement s'interrompre au démarrage, en indiquant que la RAM disponible est inférieure à la capacité de l'ordinateur ? 2 GB ? Ou doit-elle continuer, et au moment où la mémoire requise dépasse 2 GB ou simplement abandonner et sortir avec un message indiquant qu'il n'y a pas assez de mémoire disponible ?

2. Il n'est pas possible d'empêcher la manipulation de la mémoire. Il existe des millions de logiciels, et même si chacun d'entre eux ne disposait que de quelques minutes de mémoire, il serait impossible d'éviter les problèmes de mémoire. 1 kB la mémoire totale requise dépasserait 16 GB ce qui est plus que ce que la plupart des appareils offrent. Comment, dès lors, attribuer à différents logiciels des emplacements mémoire qui n'empiètent pas sur les zones des autres ? Tout d'abord, il n'existe pas de marché centralisé des logiciels qui puisse réglementer le fait que lorsqu'un nouveau logiciel est lancé, il doit s'attribuer cette quantité de mémoire de cette zone encore inoccupée Deuxièmement, même si c'était le cas, il n'est pas possible de le faire car le nombre de logiciels est pratiquement infini (ce qui nécessite une mémoire infinie pour les accueillir tous), et la RAM totale disponible sur un appareil n'est pas suffisante pour accueillir ne serait-ce qu'une fraction de ce qui est nécessaire, ce qui rend inévitable l'empiètement des limites de mémoire d'un logiciel sur celles d'un autre. Que se passe-t-il donc lorsque Photoshop se voit attribuer des emplacements mémoire 1 à 1023 y VLC est attribué 1000 à 1676 ? Et si Photoshop stocke des données à l'emplacement 1008 alors VLC écrase ces données avec ses propres données, et plus tard Photoshop y accède en pensant qu'il s'agit des mêmes données que celles qui y étaient stockées auparavant ? Comme vous pouvez l'imaginer, de mauvaises choses vont se produire.

Ainsi, comme vous pouvez le constater, cette idée est plutôt naïve.

Solution possible 2 : Essayons un autre schéma - où le système d'exploitation fera la majorité de la gestion de la mémoire. Les logiciels, lorsqu'ils ont besoin de mémoire, n'ont qu'à en faire la demande au système d'exploitation, qui s'en chargera. Le système d'exploitation s'assure qu'à chaque fois qu'un nouveau processus demande de la mémoire, il alloue la mémoire à partir de l'adresse d'octet la plus basse possible (comme nous l'avons dit précédemment, la RAM peut être imaginée comme un tableau linéaire d'octets, donc pour une adresse de type 4 GB RAM, la plage d'adresses pour un octet de 0 à 2^32-1 ) si le processus est en cours de démarrage, sinon, s'il s'agit d'un processus en cours d'exécution qui demande de la mémoire, l'allocation se fera à partir du dernier emplacement mémoire où le processus réside encore. Puisque les logiciels émettront des adresses sans tenir compte de l'adresse mémoire réelle où ces données seront stockées, le système d'exploitation devra maintenir un mappage, par logiciel, de l'adresse émise par le logiciel à l'adresse physique réelle (Note : c'est l'une des deux raisons pour lesquelles nous appelons ce concept Virtual Memory . Les logiciels ne se soucient pas de l'adresse réelle de la mémoire où leurs données sont stockées, ils se contentent d'envoyer des adresses à la volée, et le système d'exploitation trouve le bon endroit pour les placer et les retrouver plus tard si nécessaire).

Supposons que l'appareil vient d'être allumé, que le système d'exploitation vient d'être lancé, qu'aucun autre processus n'est en cours d'exécution (à l'exception du système d'exploitation, qui est également un processus ! VLC . Donc VLC se voit attribuer une partie de la RAM à partir des adresses d'octets les plus basses. Bien. Maintenant, pendant que la vidéo est en cours d'exécution, vous devez lancer votre navigateur pour afficher une page Web. Ensuite, vous devez lancer Bloc-notes pour griffonner du texte. Et puis Eclipse pour faire un peu de codage Très vite, votre mémoire de 4 GB est épuisé, et la RAM ressemble à ceci :

                                   

Problème 1 : Vous ne pouvez plus lancer d'autres processus, car toute la mémoire vive est utilisée. Les programmes doivent donc être écrits en gardant à l'esprit la mémoire maximale disponible (en pratique, il y en aura encore moins, car d'autres logiciels fonctionneront aussi en parallèle !) En d'autres termes, vous ne pouvez pas exécuter une application à forte consommation de mémoire dans votre ordinateur délabré. 1 GB PC.

Ok, donc maintenant vous décidez que vous n'avez plus besoin de garder Eclipse y Chrome ouverts, vous les fermez pour libérer de la mémoire. L'espace occupé par ces processus dans la RAM est récupéré par le système d'exploitation, et voici à quoi il ressemble maintenant :

                                    

Supposons que la fermeture de ces deux-là libère 700 MB espace - ( 400 + 300 ) MB. Vous devez maintenant lancer Opéra qui occupera 450 MB espace. Eh bien, vous avez plus que 450 MB espace disponible au total, mais... il n'est pas contigu, il est divisé en morceaux individuels, dont aucun n'est assez grand pour s'adapter à l'espace disponible. 450 MB . Vous avez donc eu une idée brillante : déplaçons tous les processus du bas vers le haut autant que possible, ce qui laissera le 700 MB espace vide dans un morceau en bas. C'est ce qu'on appelle compaction . Super, sauf que... tous les processus qui sont là sont en cours d'exécution. Les déplacer signifiera déplacer l'adresse de tous leurs contenus (rappelez-vous, le système d'exploitation maintient un mappage de la mémoire crachée par le logiciel à l'adresse mémoire réelle. Imaginons que le logiciel ait craché une adresse de 45 avec des données 123 et OS l'avait stocké dans un endroit 2012 et a créé une entrée dans la carte, mettant en correspondance 45 à 2012 . Si le logiciel est maintenant déplacé en mémoire, ce qui se trouvait à l'emplacement 2012 ne sera plus à 2012 mais dans un nouvel emplacement, et OS doit mettre à jour la carte en conséquence pour cartographier 45 à la nouvelle adresse, afin que le logiciel puisse obtenir les données attendues ( 123 ) lorsqu'il interroge l'emplacement mémoire 45 . En ce qui concerne le logiciel, tout ce qu'il sait est que l'adresse 45 contient les données 123 !) ! Imaginez un processus qui fait référence à une variable locale i . Au moment où l'on y accède à nouveau, son adresse a changé, et on ne pourra plus le retrouver. Il en va de même pour toutes les fonctions, les objets, les variables, en fait tout a une adresse, et déplacer un processus signifie changer l'adresse de tous ces éléments. Ce qui nous amène à :

Problème 2 : Vous ne pouvez pas déplacer un processus. Les valeurs de toutes les variables, fonctions et objets à l'intérieur de ce processus ont des valeurs codées en dur, comme le compilateur l'a fait lors de la compilation. par le compilateur au cours de la compilation, le processus dépend de leur le processus dépend du fait qu'elles soient au même endroit pendant sa durée de vie, et les modifier est coûteux. Par conséquent, le processus les processus laissent derrière eux de gros " holes " lorsqu'ils quittent. C'est ce qu'on appelle External Fragmentation .

Bien. Supposons que d'une manière ou d'une autre, par miracle, vous parveniez à faire remonter les processus. Maintenant il y a 700 MB d'espace libre en bas :

                        

Opéra s'insère en douceur au fond. Maintenant, votre RAM ressemble à ceci :

                                    

Bien. Tout se présente bien. Cependant, il ne reste plus beaucoup d'espace, et vous devez maintenant lancer Chrome encore une fois, une personne connue pour ses problèmes de mémoire ! Il a besoin de beaucoup de mémoire pour démarrer, et vous n'en avez presque plus... Sauf que... vous remarquez maintenant que certains des processus, qui occupaient initialement un grand espace, n'ont plus besoin de beaucoup d'espace. Vous avez peut-être arrêté votre vidéo en VLC Il occupe donc toujours un peu d'espace, mais pas autant qu'il le faudrait pour une vidéo haute résolution. De même, pour Bloc-notes y Photos . Votre RAM ressemble maintenant à ceci :

                                        

Holes une fois de plus ! Retour à la case départ ! Sauf que, auparavant, les trous se produisaient à cause de processus qui se terminaient, maintenant c'est à cause de processus qui nécessitent moins d'espace qu'avant ! Et vous avez à nouveau le même problème, le holes combinés donnent plus d'espace que nécessaire, mais ils sont éparpillés un peu partout et ne sont pas très utiles isolément. Il faut donc déplacer à nouveau ces processus, une opération coûteuse et très fréquente, car la taille des processus diminue fréquemment au cours de leur vie.

Problème 3 : Les processus, au cours de leur durée de vie, peuvent réduire leur taille, laissant derrière eux de l'espace inutilisé qui, s'il doit être utilisé, nécessitera une opération coûteuse de déplacement de nombreux processus. l'opération coûteuse de déplacer de nombreux processus. Ce phénomène est appelé Internal Fragmentation .

Bien, donc maintenant, votre système d'exploitation fait ce qu'il faut, déplace les processus et commence Chrome et après quelque temps, votre RAM ressemble à ça :

Cool. Maintenant, supposons que vous recommencez à regarder Avatar sur VLC . Ses besoins en mémoire vont augmenter ! Mais... il n'y a plus d'espace pour qu'il puisse se développer, car... Bloc-notes est blotti au fond. Donc, encore une fois, tous les processus doivent se déplacer en dessous jusqu'à ce que VLC a trouvé un espace suffisant !

Problème 4 : si les processus doivent s'étendre, l'opération sera très coûteuse.

Bien. Maintenant, supposons, Photos est utilisé pour charger des photos à partir d'un disque dur externe. L'accès au disque dur vous fait passer du royaume des caches et de la RAM à celui du disque, qui est plus lent de plusieurs ordres de grandeur. Douloureusement, irrévocablement, transcendantalement plus lent. Il s'agit d'une opération d'entrée/sortie, ce qui signifie qu'elle n'est pas liée au processeur (c'est plutôt l'exact opposé), ce qui signifie qu'elle n'a pas besoin d'occuper de la RAM pour le moment. Cependant, elle occupe toujours obstinément la RAM. Si vous voulez lancer Firefox en attendant, vous ne pouvez pas, car il n'y a pas beaucoup de mémoire disponible, alors que si Photos a été retiré de la mémoire pendant toute la durée de son activité liée aux E/S, il aurait libéré beaucoup de mémoire, suivi d'un compactage (coûteux), suivi de Firefox à l'intérieur.

Problème 5 : les tâches liées aux E/S continuent d'occuper la RAM, ce qui entraîne une sous-utilisation de la RAM, qui aurait pu être utilisée entre-temps par les tâches liées au CPU.

Donc, comme nous pouvons le voir, nous avons tellement de problèmes même avec l'approche de la mémoire virtuelle.

---

Il existe deux approches pour résoudre ces problèmes - paging y segmentation . Nous allons discuter paging . Dans cette approche, l'espace d'adressage virtuel d'un processus est mappé sur la mémoire physique en morceaux - appelés pages . Un exemple typique page la taille est 4 kB . Le mappage est maintenu par quelque chose appelé page table étant donné une adresse virtuelle, il ne nous reste plus qu'à trouver quelle page l'adresse appartient, puis de la page table trouver l'emplacement correspondant à cette page dans la mémoire physique réelle (connue sous le nom de frame ), et étant donné que le décalage de l'adresse virtuelle dans le fichier page est le même pour le page ainsi que le frame pour trouver l'adresse réelle en ajoutant ce décalage à l'adresse renvoyée par la fonction page table . Par exemple :

À gauche, l'espace d'adressage virtuel d'un processus. Disons que l'espace d'adressage virtuel nécessite 40 unités de mémoire. Si l'espace d'adressage physique (à droite) disposait lui aussi de 40 unités de mémoire, il aurait été possible de faire correspondre tous les emplacements de gauche à un emplacement de droite, et nous aurions été si heureux. Mais comme par malchance, non seulement la mémoire physique a moins (24 ici) d'unités de mémoire disponibles, mais elle doit aussi être partagée entre plusieurs processus ! Bien, voyons comment nous allons nous en accommoder.

Lorsque le processus démarre, disons qu'une demande d'accès à la mémoire pour l'emplacement 35 est réalisé. Ici, la taille de la page est 8 (chaque page contient 8 l'ensemble de l'espace d'adressage virtuel de 40 contient donc 5 pages). Cet emplacement appartient donc à la page no. 4 ( 35/8 ). Dans ce page cet emplacement a un décalage de 3 ( 35%8 ). Cet emplacement peut donc être spécifié par le tuple (pageIndex, offset) = (4,3) . Ce n'est que le début, donc aucune partie du processus n'est encore stockée dans la mémoire physique réelle. Ainsi, le page table qui maintient une correspondance entre les pages de gauche et les pages réelles de droite (où elles sont appelées frames ) est actuellement vide. Le système d'exploitation abandonne donc l'unité centrale et laisse un pilote de périphérique accéder au disque et récupérer le numéro de page. 4 pour ce processus (en fait, un morceau de mémoire du programme sur le disque dont les adresses sont comprises entre 0 et 1. 32 à 39 ). Lorsqu'il arrive, le système d'exploitation alloue la page quelque part dans la mémoire vive, disons la première trame elle-même, et l'élément page table pour ce processus prend note que la page 4 cartes pour le cadre 0 dans la RAM. Maintenant, les données sont enfin présentes dans la mémoire physique. Le système d'exploitation interroge à nouveau la table des pages pour le n-uplet (4,3) et cette fois-ci, le tableau des pages indique que la page 4 est déjà affectée à la trame 0 dans la RAM. Donc le système d'exploitation va simplement dans la 0 e trame en RAM, accède aux données à l'offset 3 dans ce cadre (Prenez un moment pour comprendre cela. L'ensemble du page qui a été récupéré du disque, est déplacé vers frame . Ainsi, quel que soit le décalage d'un emplacement de mémoire individuel dans une page, il sera également le même dans la trame, puisque dans le cadre de la page page / frame l'unité de mémoire se trouve toujours au même endroit, relativement !), et renvoie les données ! Étant donné que les données n'ont pas été trouvées en mémoire lors de la première requête, mais qu'elles ont dû être extraites du disque pour être chargées en mémoire, il s'agit d'une requête de type miss .

Bien. Maintenant, supposons qu'un accès mémoire pour l'emplacement 28 est fait. Cela se résume à (3,4) . Page table n'a pour l'instant qu'une seule entrée, la page de cartographie 4 au cadre 0 . Donc, c'est encore une fois miss le processus abandonne le CPU, le pilote de périphérique va chercher la page sur le disque, le processus reprend le contrôle du CPU, et son page table est mis à jour. Disons maintenant que la page 3 est mis en correspondance avec la trame 1 dans la RAM. Donc (3,4) devient (1,4) et les données se trouvant à cet emplacement dans la RAM sont renvoyées. Bien. De cette façon, supposons que le prochain accès mémoire concerne l'emplacement 8 ce qui se traduit par (1,0) . Page 1 n'est pas encore en mémoire, la même procédure est répétée, et l'élément page est alloué à la trame 2 dans la RAM. Le mappage RAM-processus ressemble maintenant à l'image ci-dessus. À ce stade, la RAM, qui ne disposait que de 24 unités de mémoire, est remplie. Supposons que la prochaine demande d'accès à la mémoire de ce processus provienne de l'adresse 30 . Il correspond à (3,6) y page table indique que la page 3 est dans la RAM, et il est relié à la trame 1 . Oui ! Donc les données sont extraites de la RAM. (1,6) et est revenu. Ceci constitue un touchez car les données requises peuvent être obtenues directement de la RAM, ce qui est très rapide. De même, les quelques demandes d'accès suivantes, par exemple pour les emplacements 11 , 32 , 26 , 27 tous sont touche En d'autres termes, les données demandées par le processus sont trouvées directement dans la RAM sans qu'il soit nécessaire de chercher ailleurs.

Supposons maintenant qu'une demande d'accès à la mémoire pour l'emplacement 3 vient. Cela se traduit par (0,3) y page table pour ce processus, qui compte actuellement 3 entrées, pour les pages 1 , 3 y 4 dit que cette page n'est pas en mémoire. Comme dans les cas précédents, elle est récupérée sur le disque, mais, contrairement aux cas précédents, la RAM est remplie ! Alors que faire maintenant ? C'est là que réside la beauté de la mémoire virtuelle, un cadre de la RAM est expulsé ! (Différents facteurs déterminent quel cadre doit être expulsé. Il peut s'agir LRU où le cadre qui a été le moins récemment accédé pour un processus doit être évincé. Cela peut être first-come-first-evicted où la trame qui a été allouée le plus longtemps auparavant est évincée, etc.) Ainsi, une trame est évincée. Disons la trame 1 (en la choisissant au hasard). Cependant, cette frame est mis en correspondance avec un certain page ! (Actuellement, il est mappé par la table des pages à la page 3 de notre seul et unique processus). Donc, ce processus doit être informé de cette tragique nouvelle, qu'un seul frame qui vous appartient malheureusement, doit être expulsé de la RAM pour faire de la place à une autre pages . Le processus doit s'assurer qu'il met à jour son page table avec cette information, c'est-à-dire qu'il supprime l'entrée pour ce duo de cadres de page, de sorte que la prochaine fois qu'une demande sera faite pour ce duo de cadres de page, il n'y aura plus d'entrée. page il dit directement au processus que cette page n'est plus en mémoire, et doit être récupéré sur le disque. Bien. Donc le cadre 1 est expulsée, la page 0 est amené et placé là dans la RAM, et l'entrée pour la page 3 est supprimée, et remplacée par la page 0 pour le même cadre 1 . Notre mappage ressemble maintenant à ceci (notez le changement de couleur dans la deuxième colonne). frame sur le côté droit) :

Tu as vu ce qui vient de se passer ? Le processus devait se développer, il avait besoin de plus d'espace que la RAM disponible, mais contrairement à notre scénario précédent où tous les processus dans la RAM devaient se déplacer pour accueillir un processus en croissance, ici, cela s'est produit par un seul processus page remplacement ! Cela a été rendu possible par le fait que la mémoire d'un processus n'a plus besoin d'être contiguë, elle peut résider à différents endroits en morceaux, le système d'exploitation conserve les informations sur l'endroit où ils se trouvent, et quand c'est nécessaire, ils sont interrogés de manière appropriée. Remarque : vous vous dites peut-être : "Et si, la plupart du temps, il s'agissait d'un processus de type miss et les données doivent être constamment chargées du disque vers la mémoire ? Oui, théoriquement, c'est possible, mais la plupart des compilateurs sont conçus de manière à ce que locality of reference En d'autres termes, si les données d'un emplacement de mémoire sont utilisées, les prochaines données nécessaires seront situées à un endroit très proche, peut-être dans le même emplacement de mémoire. page El page qui vient d'être chargé en mémoire. En conséquence, le prochain manque se produira après un certain temps, la plupart des besoins en mémoire à venir seront satisfaits par la page qui vient d'être chargée, ou par les pages déjà en mémoire qui ont été récemment utilisées. Le même principe nous permet d'expulser la page la moins récemment utilisée. page en partant du principe que ce qui n'a pas été utilisé pendant un certain temps ne sera probablement pas utilisé pendant un certain temps également. Cependant, ce n'est pas toujours le cas, et dans des cas exceptionnels, oui, les performances peuvent en pâtir. Nous y reviendrons plus tard.

Solution au problème 4 : Les processus peuvent maintenant se développer facilement, si un problème d'espace est rencontré, il suffit de faire une simple page remplacement, sans déplacer aucun autre processus.

---

Solution au problème 1 : Un processus peut accéder à une mémoire illimitée. Lorsqu'il a besoin de plus de mémoire que celle dont il dispose, le disque est utilisé comme sauvegarde, les nouvelles données requises sont chargées en mémoire à partir du disque et les données les moins récemment utilisées. frame (o page ) est déplacé sur le disque. Ce processus peut se poursuivre à l'infini, et comme l'espace disque est bon marché et pratiquement illimité, il donne l'illusion d'une mémoire illimitée. Une autre raison du nom Virtual Memory Cela vous donne l'illusion d'une mémoire qui n'est pas réellement disponible !

Cool. Auparavant, nous étions confrontés à un problème où, même si un processus réduit sa taille, l'espace vide est difficile à récupérer par d'autres processus (car cela nécessiterait une compaction coûteuse). Maintenant, c'est facile, lorsqu'un processus devient plus petit, beaucoup de ses processus sont remplacés par d'autres. pages ne sont plus utilisés, donc lorsque d'autres processus ont besoin de plus de mémoire, une simple LRU L'éviction basée sur la technologie permet d'évincer automatiquement les données les moins utilisées. pages de la RAM, et les remplace par les nouvelles pages des autres processus (et, bien sûr, en mettant à jour les pages de la page tables de tous ces processus ainsi que du processus original qui nécessite désormais moins d'espace), le tout sans aucune opération coûteuse de compactage !

Solution au problème 3 : Lorsque la taille d'un processus diminue, ses frames dans la RAM sera moins utilisée, donc une simple LRU basée sur l'éviction peut évincer ces pages et les remplacer par pages requis par les nouveaux processus, évitant ainsi Internal Fragmentation sans avoir besoin de compaction .

Quant au problème 2, prenez un moment pour le comprendre, le scénario lui-même est complètement supprimé ! Il n'y a pas besoin de déplacer un processus pour accueillir un nouveau processus, parce que maintenant le processus entier n'a jamais besoin de s'adapter en même temps, seulement certaines pages de celui-ci doivent s'adapter ad hoc, cela se produit en expulsant frames de la RAM. Tout se passe en unités de pages Il n'y a donc pas de concept de hole maintenant, et donc pas question que quelque chose bouge ! Peut-être 10 pages ont dû être déplacés en raison de cette nouvelle exigence, il y a des milliers de pages qui sont laissés intacts. Alors qu'auparavant, tous les processus (chacun d'entre eux) devaient être déplacés !

Solution au problème 2 : Pour accueillir un nouveau processus, les données des parties les moins récemment utilisées des autres processus doivent être expulsées selon les besoins, et cela se fait par unités de taille fixe appelées pages . Il n'y a donc aucune possibilité de hole o External Fragmentation avec ce système.

Maintenant, lorsque le processus a besoin d'effectuer une opération d'E/S, il peut céder le CPU facilement ! Le système d'exploitation expulse simplement tous ses pages de la RAM (peut-être en la stockant dans un cache) tandis que de nouveaux processus occupent la RAM pendant ce temps. Lorsque l'opération d'entrée/sortie est terminée, le système d'exploitation restaure simplement ces données. pages à la RAM (bien sûr en remplaçant le pages à partir d'autres processus, qui peuvent être ceux qui ont remplacé le processus original, ou qui peuvent être ceux qui ont eux-mêmes besoin de faire des E/S maintenant, et qui peuvent donc renoncer à la mémoire !)

Solution au problème 5 : Lorsqu'un processus effectue des opérations d'E/S, il peut facilement renoncer à l'utilisation de la RAM, qui peut être utilisée par d'autres processus. Cela conduit à une utilisation appropriée de la RAM.

Et bien sûr, maintenant aucun processus n'accède directement à la RAM. Chaque processus accède à un emplacement de mémoire virtuel, qui est mappé sur une adresse de RAM physique et maintenu par le système de gestion de la mémoire. page-table de ce processus. Le mappage est soutenu par le système d'exploitation, qui fait savoir au processus quelle trame est vide afin qu'une nouvelle page pour un processus puisse y être placée. Puisque cette allocation de mémoire est supervisée par le système d'exploitation lui-même, il peut facilement s'assurer qu'aucun processus n'empiète sur le contenu d'un autre processus en n'allouant que des cadres vides de la RAM ou, s'il empiète sur le contenu d'un autre processus dans la RAM, communiquer avec le processus pour le mettre à jour. page-table .

Solution au problème original : Il n'y a aucune possibilité pour un processus d'accéder au contenu d'un autre processus, puisque l'allocation entière est gérée par le système d'exploitation lui-même, et que chaque processus fonctionne dans son propre espace d'adresse virtuelle.

Alors paging (entre autres techniques), en conjonction avec la mémoire virtuelle, est ce qui fait fonctionner les logiciels d'aujourd'hui sur les OS-es ! Le développeur de logiciels n'a plus à se soucier de la quantité de mémoire disponible sur l'appareil de l'utilisateur, de l'endroit où stocker les données, de la manière d'empêcher d'autres processus de corrompre les données de son logiciel, etc. Toutefois, ce système n'est bien sûr pas totalement infaillible. Il existe des failles :

1. Paging c'est, en définitive, donner à l'utilisateur l'illusion d'une mémoire infinie en utilisant le disque comme sauvegarde secondaire. La récupération des données du stockage secondaire pour les faire tenir dans la mémoire (appelé page swap et le fait de ne pas trouver la page désirée dans la RAM est appelé page fault ) est coûteux car il s'agit d'une opération d'entrée/sortie. Cela ralentit le processus. Plusieurs échanges de pages de ce type se succèdent, et le processus devient douloureusement lent. Vous avez déjà vu votre logiciel fonctionner à merveille, et soudain il devient si lent qu'il se bloque presque, ou ne vous laisse pas d'autre choix que de le redémarrer ? Il est possible qu'il y ait eu trop de changements de page, ce qui l'a ralenti (appelé thrashing ).

Pour en revenir à l'OP,

Pourquoi avons-nous besoin de la mémoire virtuelle pour exécuter un processus ? - Comme l'explique longuement la réponse, il s'agit de donner aux logiciels l'illusion que l'appareil/le système d'exploitation dispose d'une mémoire infinie, de sorte que n'importe quel logiciel, petit ou grand, puisse être exécuté sans se soucier de l'allocation de la mémoire ou de la corruption de ses données par d'autres processus, même s'il est exécuté en parallèle. Il s'agit d'un concept, mis en œuvre dans la pratique par le biais de diverses techniques, dont l'une, décrite ici, est la suivante Paging . Il peut également être Segmentation .

Où se trouve cette mémoire virtuelle lorsque le processus (programme) du disque dur externe est amené dans la mémoire principale (mémoire physique) pour l'exécution ? - La mémoire virtuelle ne se trouve nulle part en soi, c'est une abstraction, toujours présente, lorsque le logiciel/processus/programme est démarré, une nouvelle table de pages est créée pour lui, et elle contient le mappage des adresses crachées par ce processus à l'adresse physique réelle dans la RAM. Puisque les adresses crachées par le processus ne sont pas des adresses réelles, dans un sens, elles sont, en fait, ce que vous pouvez dire, the virtual memory .

Qui s'occupe de la mémoire virtuelle et quelle est la taille de la mémoire virtuelle ? - Elle est prise en charge par, en tandem, le système d'exploitation et le logiciel. Imaginez une fonction dans votre code (qui a finalement été compilé et transformé en l'exécutable qui a engendré le processus) qui contient une variable locale - une variable de type int i . Lorsque le code s'exécute, i obtient une adresse mémoire dans la pile de la fonction. Cette fonction est elle-même stockée comme un objet quelque part ailleurs. Ces adresses sont générées par le compilateur (le compilateur qui a compilé votre code dans l'exécutable) - adresses virtuelles. Lors de l'exécution, i doit résider quelque part dans l'adresse physique actuelle pendant la durée de cette fonction au moins (à moins qu'il ne s'agisse d'une variable statique !), de sorte que OS fait correspondre l'adresse virtuelle générée par le compilateur de i en une adresse physique réelle, de sorte que chaque fois que, dans cette fonction, un code requiert la valeur de i ce processus peut demander au système d'exploitation cette adresse virtuelle, et le système d'exploitation peut à son tour demander à l'adresse physique la valeur stockée, et la renvoyer.

Supposons que la taille de la RAM soit de 4 Go (soit 2^32-1 espaces d'adressage), quelle est la taille de la mémoire virtuelle ? - La taille de la RAM n'est pas liée à la taille de la mémoire virtuelle, elle dépend du système d'exploitation. Par exemple, sous Windows 32 bits, il s'agit de 16 TB Sous Windows 64 bits, c'est 256 TB . Bien entendu, il est également limité par la taille du disque, puisque c'est là que la mémoire est sauvegardée.

Answer 2

La mémoire virtuelle est, entre autres, une abstraction qui donne au programmeur l'illusion de disposer d'une mémoire infinie sur son système.

Les mappages de la mémoire virtuelle sont faits pour correspondre aux adresses physiques réelles. Le site système d'exploitation crée et traite ces mappages - en utilisant la table des pages, parmi d'autres structures de données pour maintenir les mappages. Les mappages de la mémoire virtuelle se trouvent toujours dans la table des pages ou dans une structure de données similaire (dans le cas d'autres implémentations de la mémoire virtuelle, nous ne devrions peut-être pas l'appeler la "table des pages"). La table des pages se trouve également dans la mémoire physique - souvent dans des espaces réservés par le noyau sur lesquels les programmes utilisateurs ne peuvent pas écrire.

La mémoire virtuelle est généralement plus grande que la mémoire physique. Les mappages de mémoire virtuelle n'auraient pas beaucoup de raison d'être si la mémoire virtuelle et la mémoire physique avaient la même taille.

Seule la partie nécessaire d'un programme est résidente en mémoire, en général - c'est un sujet appelé "pagination". La mémoire virtuelle et la pagination sont étroitement liées, mais no le même sujet. Il existe d'autres implémentations de la mémoire virtuelle, comme la segmentation.

Je peux me tromper ici, mais je parie que les choses que vous avez du mal à comprendre ont à voir avec des implémentations spécifiques de la mémoire virtuelle, très probablement la pagination. Il n'y a pas de un sens pour faire de la pagination - il existe de nombreuses implémentations et celle que votre manuel décrit n'est probablement pas la même que celle qui apparaît dans les systèmes d'exploitation réels comme Linux/Windows - il y a probablement des différences subtiles.

Je pourrais écrire un millier de paragraphes sur la pagination... mais je pense qu'il est préférable de laisser ce sujet à une autre question portant spécifiquement sur ce sujet.

Answer 3

Je copie sans vergogne les extraits de la page de l'homme du top.

VIRT -- Image virtuelle (kb) La quantité totale de mémoire virtuelle utilisée par la tâche. Elle comprend l'ensemble du code, des données et des bibliothèques partagées, ainsi que les pages qui ont été mises à jour. qui ont été transférées et les pages qui ont été mappées mais non utilisées.

SWAP -- Taille échangée (kb) Mémoire qui n'est pas résidente mais qui est présente dans une tâche. Il s'agit de la mémoire qui a été échangée, mais qui peut inclure des données non résidentes supplémentaires. résidente. Cette colonne est calculée par soustraire la mémoire physique de la mémoire virtuelle

Answer 4

Voir ici : Mémoire physique et mémoire virtuelle

La mémoire virtuelle est stockée sur le disque dur et est utilisée lorsque la RAM est remplie. La mémoire physique est limitée à la taille des puces RAM installées dans l'ordinateur. La mémoire virtuelle est limitée par la taille du disque dur. La mémoire virtuelle a donc la possibilité de stocker davantage de données.

Answer 5

Mémoire physique : La mémoire physique désigne la mémoire vive ou la mémoire primaire de l'ordinateur. La mémoire physique est une mémoire volatile. Par conséquent, elle nécessite un flux continu d'énergie pour conserver les données.

Mémoire virtuelle est une mémoire logique. En d'autres termes, il s'agit d'une technique de gestion de la mémoire réalisée par le système d'exploitation. La mémoire virtuelle permet au programmeur d'utiliser plus de mémoire pour les programmes que la mémoire physique disponible. Si la mémoire physique est de 4 Go et la mémoire virtuelle de 16 Go, le programmeur peut utiliser la mémoire virtuelle de 16 Go pour exécuter le programme. En utilisant la mémoire virtuelle, il peut exécuter des programmes complexes qui nécessitent plus de mémoire que la mémoire physique.

La principale différence entre la mémoire physique et la mémoire virtuelle est que la mémoire physique fait référence à la mémoire vive réelle du système fixée à la carte mère, tandis que la mémoire virtuelle est une technique de gestion de la mémoire qui permet aux utilisateurs d'exécuter des programmes plus importants que la mémoire physique réelle.