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

Je suis souvent confondu avec le concept de virtualisation dans les systèmes d'exploitation. Considérant la RAM comme la mémoire physique, pourquoi avons-nous besoin de la mémoire virtuelle pour exécuter un processus?

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.

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

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

La mémoire virtuelle est, entre autres, une abstraction pour donner au programmeur l'illusion d'avoir une mémoire infinie disponible sur son système.

Les mappages de mémoire virtuelle sont faits pour correspondre aux adresses physiques réelles. Le système d'exploitation crée et gère ces mappages - en utilisant la table des pages, entre autres structures de données, pour maintenir les mappages. Les mappages de 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 mémoire virtuelle, nous ne devrions peut-être pas l'appeler la «table des pages»). La table des pages est également en mémoire physique - souvent dans des espaces réservés au noyau que les programmes utilisateur ne peuvent pas écraser.

La mémoire virtuelle est généralement plus grande que la mémoire physique - il n'y aurait pas beaucoup de raisons pour les mappages de mémoire virtuelle si la mémoire virtuelle et la mémoire physique avaient la même taille.

Seule la partie nécessaire d'un programme réside en mémoire, généralement - il s'agit d'un sujet appelé «pagination». La mémoire virtuelle et la pagination sont étroitement liées, mais pas le même sujet. Il existe d'autres implémentations de mémoire virtuelle, telles que la segmentation.

Je pourrais supposer que c'est faux 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, probablement la pagination. Il n'y a pas une seule façon de faire 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 existe probablement des différences subtiles.

Je pourrais écrire un millier de paragraphes sur la pagination ... mais je pense qu'il vaut mieux laisser une question différente ciblant spécifiquement ce sujet.

Les logiciels fonctionnent sur le système d'exploitation sur un principe très simple - ils nécessitent de la mémoire. Le système d'exploitation de l'appareil le fournit sous forme de RAM. La quantité de mémoire requise peut varier - certains logiciels nécessitent une mémoire énorme, certains nécessitent une mémoire dérisoire. La plupart des utilisateurs (sinon 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 de l'appareil est limitée), la quantité de mémoire disponible est toujours limitée. Donc, étant donné que tous les logiciels nécessitent une certaine quantité de RAM et que tous peuvent être exécutés en même temps, le système d'exploitation doit prendre en charge deux choses:

1. Que le logiciel fonctionne toujours jusqu'à ce que l'utilisateur l'abandonne, c'est-à-dire qu'il ne doit pas s'interrompre automatiquement car le système d'exploitation est à court de mémoire.
2. L'activité ci-dessus, tout en conservant une performance respectable pour les logiciels en cours d'exécution.

Maintenant, la question principale se résume à la façon dont la mémoire est gérée. Qu'est-ce qui régit exactement où dans la mémoire les données appartenant à un logiciel donné résideront?

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

Avantages:

1. Chaque application est pré-assignée à un emplacement mémoire, donc lorsqu'elle est installée et exécutée, elle stocke simplement ses données dans cette zone mémoire, et tout fonctionne bien.

Désavantages:

1. Cela ne s'adapte pas. Théoriquement, une application peut nécessiter une énorme quantité de mémoire lorsqu'elle fait quelque chose de vraiment lourd. Ainsi, pour s'assurer qu'il ne manque jamais de mémoire, la zone mémoire qui lui est allouée doit toujours être supérieure ou égale à cette quantité de mémoire. Et si un logiciel, dont l'utilisation théorique maximale de la mémoire est 2 GB(nécessitant donc une 2 GBallocation de mémoire à partir de la RAM), était installé sur une machine avec uniquement de la 1 GBmémoire? Le logiciel doit-il simplement abandonner au démarrage, en disant que la RAM disponible est inférieure à 2 GB? Ou devrait-il continuer, et au moment où la mémoire requise dépasse 2 GB, il suffit d'abandonner et de renflouer avec le message qu'il n'y a pas assez de mémoire disponible?

2. Il n'est pas possible d'empêcher la détérioration de la mémoire. Il existe des millions de logiciels, même si chacun d'entre eux n'avait que de la 1 kBmémoire, la mémoire totale requise dépasserait 16 GB, ce qui est plus que ce que la plupart des appareils offrent. Comment peut-on alors attribuer à différents logiciels des emplacements mémoire qui n'empiètent pas les uns sur les autres? Premièrement, il n'y a pas de marché logiciel centralisé qui puisse réglementer que lorsqu'un nouveau logiciel est publié, il doit s'attribuer autant de mémoire à partir de cette zone encore inoccupée., et deuxièmement, même s'il y en avait, il n'est pas possible de le faire car le non. des logiciels est pratiquement infini (nécessitant ainsi une mémoire infinie pour les accueillir tous), et la RAM totale disponible sur n'importe quel appareil n'est pas suffisante pour accueillir ne serait-ce qu'une fraction de ce qui est nécessaire, rendant ainsi inévitable l'empiètement des limites de la mémoire d'un logiciel sur celui d'un autre. Alors qu'est - ce qui se passe lorsque Photoshop est attribué emplacements de mémoire 1à 1023et VLC est attribué 1000à 1676? Et si Photoshop stockait certaines données à l'emplacement 1008, alors VLC les écrasait avec ses propres données, et plus tard Photoshopy accède en pensant que ce sont les mêmes données qui y ont été stockées précédemment? Comme vous pouvez l'imaginer, de mauvaises choses vont arriver.

Donc clairement, comme vous pouvez le voir, 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, chaque fois qu'ils ont besoin de mémoire, demandent simplement le système d'exploitation et le système d'exploitation s'adaptera en conséquence. Say OS garantit que chaque fois qu'un nouveau processus demande de la mémoire, il allouera la mémoire à partir de l'adresse d'octet la plus basse possible (comme dit précédemment, la RAM peut être imaginée comme un tableau linéaire d'octets, donc pour une 4 GBRAM, la plage d'adresses pour un octet de 0à2^32-1) si le processus démarre, sinon s'il s'agit d'un processus en cours d'exécution demandant la mémoire, il allouera à partir du dernier emplacement de mémoire où ce processus réside toujours. Étant donné que les logiciels émettront des adresses sans tenir compte de l'adresse mémoire réelle où ces données sont 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 (Remarque: c'est l'une des deux raisons pour lesquelles nous appelons ce concept.Les Virtual Memorylogiciels ne se soucient pas de l'adresse mémoire réelle où leurs données sont stockées, ils crachent simplement des adresses à la volée, et le système d'exploitation trouve le bon endroit pour l'adapter et le trouver plus tard si nécessaire).

Disons que l'appareil vient d'être allumé, que le système d'exploitation vient de se lancer, pour le moment, il n'y a pas d'autre processus en cours d'exécution (en ignorant le système d'exploitation, qui est également un processus!), Et vous décidez de lancer VLC . Ainsi, VLC se voit allouer une partie de la RAM à partir des adresses d'octets les plus bas. Bien. Maintenant, pendant que la vidéo est en cours d'exécution, vous devez démarrer votre navigateur pour afficher une page Web. Ensuite, vous devez lancer le Bloc-notes pour griffonner du texte. Et puis Eclipse pour faire un peu de codage .. Bientôt, votre mémoire 4 GBest épuisée, et la RAM ressemble à ceci:

Problème 1: Vous ne pouvez maintenant démarrer aucun autre processus, car toute la RAM est épuisée. Ainsi, les programmes doivent être écrits en gardant à l'esprit le maximum de mémoire disponible (pratiquement encore moins sera disponible, car d'autres logiciels fonctionneront également en parallèle!). En d'autres termes, vous ne pouvez pas exécuter une application consommant beaucoup de mémoire sur votre 1 GBPC délabré .

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

Supposons que la fermeture de ces deux libère de l' 700 MBespace - ( 400+ 300) Mo. Vous devez maintenant lancer Opera , qui prendra de la place 450 MB. Eh bien, vous avez plus que l' 450 MBespace disponible au total, mais ... il n'est pas contigu, il est divisé en morceaux individuels, dont aucun n'est assez grand pour tenir 450 MB. Vous avez donc une idée brillante, déplaçons tous les processus ci-dessous vers le plus haut possible, ce qui laissera l' 700 MBespace vide en un seul morceau en bas. C'est appelécompaction. Génial, sauf que ... tous les processus qui sont là sont en cours d'exécution. Les déplacer signifiera déplacer l'adresse de tout leur contenu (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. Imaginez que le logiciel ait craché une adresse de 45avec des données 123, et que le système d'exploitation l'a stockée à l'emplacement 2012et a créé une entrée dans la carte, mappant 45vers 2012. Si le logiciel est maintenant déplacé en mémoire, ce qui se trouvait à l'emplacement 2012ne sera plus à 2012, mais à un nouvel emplacement, et le système d'exploitation doit mettre à jour la carte en conséquence pour mapper 45vers le nouvelle adresse, afin que le logiciel puisse obtenir les données attendues ( 123) lorsqu'il demande l'emplacement de la mémoire 45. En ce qui concerne le logiciel, tout ce qu'il sait est cette adresse45contient les données 123!)! Imaginez un processus qui fait référence à une variable locale i. Au moment où on y accède à nouveau, son adresse a changé et il ne pourra plus la trouver. Il en va de même pour toutes les fonctions, objets, variables, fondamentalement, tout a une adresse, et déplacer un processus signifiera changer l'adresse de chacun d'eux. 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 de ce processus ont des valeurs codées en dur comme crachées par le compilateur lors de la compilation, le processus dépend du fait qu'elles se trouvent au même endroit pendant sa durée de vie et leur modification est coûteuse. En conséquence, les processus laissent derrière eux de gros " holes" lorsqu'ils sortent. Cela s'appelle External Fragmentation.

Bien. Supposons que, d'une manière miraculeuse, vous parveniez à faire monter les processus. Maintenant, il y a 700 MBde l'espace libre en bas:

Opera s'intègre parfaitement en bas. Maintenant, votre RAM ressemble à ceci:

Bien. Tout va bien. Cependant, il ne reste plus beaucoup d'espace et vous devez maintenant lancer à nouveau Chrome , une mémoire connue! Il faut 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. Peut-être avez-vous arrêté votre vidéo dans VLC , elle occupe donc toujours un peu d'espace, mais pas autant que nécessaire lors de l'exécution d'une vidéo haute résolution. De même pour le bloc - notes et les photos . Votre RAM ressemble maintenant à ceci:

Holes, encore une fois! Retour à la case départ! Sauf que, auparavant, les trous se produisaient en raison de la fin des processus, maintenant c'est dû à des processus nécessitant moins d'espace qu'auparavant! Et vous avez à nouveau le même problème, le holesrendement combiné donne plus d'espace que nécessaire, mais ils sont dispersés, peu utiles isolément. Vous devez donc déplacer à nouveau ces processus, une opération coûteuse et très fréquente, car les processus réduiront fréquemment de taille au cours de leur durée de 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 est nécessaire, nécessitera l'opération coûteuse de déplacement de nombreux processus. Cela s'appelle Internal Fragmentation.

Très bien, alors maintenant, votre système d'exploitation fait la chose requise, déplace les processus et démarre Chrome et après un certain temps, votre RAM ressemble à ceci:

Cool. Supposons maintenant que vous repreniez à regarder Avatar dans VLC . Son besoin de mémoire va exploser! Mais ... il n'y a plus d'espace pour qu'il grandisse, car le Bloc - notes est blotti au fond. Donc, encore une fois, tous les processus doivent se déplacer en dessous jusqu'à ce que VLC ait trouvé suffisamment d'espace!

Problème 4: Si les processus doivent se développer, ce sera une opération très coûteuse

Bien. Supposons maintenant que Photos soit utilisé pour charger des photos à partir d'un disque dur externe. L'accès au disque dur vous emmène du domaine des caches et de la RAM à celui du disque, qui est plus lent de plusieurs ordres de grandeur. Péniblement, irrévocablement, transcendantalement plus lent. Il s'agit d'une opération d'E / S, ce qui signifie qu'elle n'est pas liée au processeur (c'est plutôt exactement le contraire), ce qui signifie qu'elle n'a pas besoin d'occuper de la RAM pour le moment. Cependant, il occupe toujours la RAM obstinément. Si vous voulez lancer Firefox entre-temps, vous ne pouvez pas, car il n'y a pas beaucoup de mémoire disponible, alors que si Photos était sorti de la mémoire pendant la durée de son activité liée aux E / S, cela aurait libéré beaucoup de mémoire, suivi d'un compactage (coûteux), suivi de l' intégration de Firefox .

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

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 s'attaquer à ces problèmes - paginget segmentation. Laissez-nous discuter paging. Dans cette approche, l'espace d'adressage virtuel d'un processus est mappé à la mémoire physique par blocs - appelés pages. Une pagetaille typique est 4 kB. Le mappage est maintenu par quelque chose appelé a page table, étant donné une adresse virtuelle, il ne nous reste plus qu'à trouver à quelle pageadresse appartient, puis à partir du page table, trouver l'emplacement correspondant pour cela pagedans la mémoire physique réelle (connue sous le nom de frame), et donné que le décalage de l'adresse virtuelle dans le pageest le même pour le pageainsi que pour le frame, recherchez l'adresse réelle en ajoutant ce décalage à l'adresse renvoyée par le page table. Par exemple:

Sur la gauche se trouve l'espace d'adressage virtuel d'un processus. Supposons que l'espace d'adressage virtuel nécessite 40 unités de mémoire. Si l'espace d'adressage physique (à droite) avait également 40 unités de mémoire, il aurait été possible de mapper tous les emplacements de la gauche vers un emplacement sur la droite, et nous aurions été si heureux. Mais par malchance, non seulement la mémoire physique a moins (24 ici) unités de mémoire disponibles, mais elle doit également être partagée entre plusieurs processus! Bien, voyons comment nous nous en sortons.

Lorsque le processus démarre, disons qu'une demande d'accès à la mémoire pour l'emplacement 35est effectuée. Ici, la taille de la page est 8(chacune pagecontient des 8emplacements, tout l'espace d'adressage virtuel des 40emplacements contient donc des 5pages). Donc, cet emplacement appartient à la page no. 4( 35/8). Dans ce cadre page, cet emplacement a un décalage de 3( 35%8). Donc, cet emplacement peut ê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. Donc le page table, qui maintient un mappage des pages sur la gauche avec les pages réelles sur la droite (où elles sont appeléesframes ) est actuellement vide. Ainsi, le système d'exploitation abandonne le processeur, permet à un pilote de périphérique d'accéder au disque et de récupérer la page no. 4pour ce processus (essentiellement un morceau de mémoire du programme sur le disque dont les adresses vont de 32à 39). Quand il arrive, le système d'exploitation alloue la page quelque part dans la RAM, disons la première image elle-même, et le page tablepour ce processus prend note que la page 4correspond à l'image0dans la RAM. Maintenant, les données sont enfin là dans la mémoire physique. Le système d'exploitation interroge à nouveau la table de page pour le tuple(4,3) , et cette fois, la table de page indique que la page 4est déjà mappée au cadre 0dans la RAM. Ainsi, le système d'exploitation passe simplement à la 0ème image de la RAM, accède aux données au décalage 3dans cette image (prenez un moment pour comprendre cela.page, qui a été extrait du disque, est déplacé vers frame. Donc, quel que soit le décalage d'un emplacement de mémoire individuel dans une page, il sera également le même dans le cadre, car dans le page/ frame, l'unité de mémoire réside toujours relativement au même endroit!), 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 elle-même, mais qu'elles ont plutôt dû être extraites du disque pour être chargées en mémoire, cela constitue un échec .

Bien. Supposons maintenant qu'un accès mémoire pour l'emplacement 28soit effectué. Cela se résume à (3,4). Page tablepour l'instant, il n'y a qu'une seule entrée, mappant la page 4au cadre 0. Il s'agit donc à nouveau d'un échec , le processus abandonne le processeur, le pilote de périphérique récupère la page du disque, le processus reprend le contrôle du processeur et il page tableest mis à jour. Disons maintenant que la page 3est mappée au cadre 1dans la RAM. Ainsi (3,4)devient (1,4), et les données à cet emplacement dans la RAM sont renvoyées. Bien. De cette manière, supposons que le prochain accès mémoire soit pour l'emplacement 8, ce qui se traduit par (1,0). La page 1n'est pas encore en mémoire, la même procédure est répétée et le pageest alloué à l'image2en RAM. Maintenant, le mappage du processus RAM ressemble à 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 pour ce processus provienne de l'adresse 30. Il correspond à (3,6), et page tableindique que la page 3est en RAM, et il correspond au cadre 1. Yay! Ainsi, les données sont extraites de l'emplacement de la RAM (1,6)et renvoyées. Cela constitue un succès , car les données requises peuvent être obtenues directement à partir de la RAM, ce qui est très rapide. De même, les prochaines demandes d'accès, par exemple pour les emplacements 11, 32,26 , 27tous sont succès , à savoir les données demandées par le processus se trouve directement dans la RAM sans avoir besoin de chercher ailleurs.

Supposons maintenant qu'une demande d'accès à la mémoire pour l'emplacement 3arrive. Il se traduit par (0,3), et page tablepour ce processus, qui a actuellement 3 entrées, pour les pages 1, 3et 4dit que cette page n'est pas en mémoire. Comme les cas précédents, il est récupéré à partir du disque, cependant, contrairement aux cas précédents, la RAM est pleine! Alors que faire maintenant? C'est là que réside la beauté de la mémoire virtuelle, une trame de la RAM est expulsée! (Divers facteurs déterminent quel cadre doit être expulsé. Il peut être LRUbasé sur l'endroit où le cadre qui a été le moins récemment consulté pour un processus doit être expulsé. Il se peut que ce soit le cas ! (Actuellement, il est mappé par le tableau de page à la page de notre un et un seul processus) .Ainsi, ce processus doit être annoncé cette tragique nouvelle, celle-làfirst-come-first-evicted base, où la trame qui a été allouée il y a le plus longtemps, est expulsée, etc. .) Ainsi, une trame est expulsée. Dites l'image 1 (en la choisissant au hasard). Cependant, cela frameest mappé à certainspage3frame , qui vous appartient malheureux, doit être expulsée de la RAM pour faire place à une autre pages. Le processus doit s'assurer qu'il met à jour ses page tableinformations avec ces informations, c'est-à-dire en supprimant l'entrée pour ce duo de cadres de page, de sorte que la prochaine fois qu'une demande est faite pour cela page, il indique correctement au processus que ce pagen'est plus en mémoire , et doit être extrait du disque. Bien. Le cadre 1est donc expulsé, la page 0est introduite et placée là dans la RAM, et l'entrée de page 3est supprimée et remplacée par le 0mappage de page vers le même cadre1. Alors maintenant, notre mapping ressemble à ceci (notez le changement de couleur dans la seconde framesur le côté droit):

Vous avez 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ù chaque processus de la RAM devait se déplacer pour s'adapter à un processus en croissance, ici, cela s'est produit par un seul pageremplacement! 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 dans des morceaux, le système d'exploitation conserve les informations sur l'endroit où elles se trouvent et, si nécessaire, elles sont interrogées de manière appropriée. Remarque: vous pensez peut-être, hein, que se passe-t-il si la plupart du temps c'est un , c'est-à-dire que si des données d'un emplacement mémoire sont utilisées, les données suivantes nécessaires seront situées quelque part très proche, peut-être du même , lemiss , et que 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 telle manière quelocality of referencepagepage qui vient d'être chargé en mémoire. En conséquence, le prochain échec se produira après un certain temps, la plupart des besoins de mémoire à venir seront satisfaits par la page qui vient d'être introduite, ou les pages déjà en mémoire qui ont été récemment utilisées. Le même principe exact nous permet d'expulser également le moins utilisé récemment page, avec la logique que ce qui n'a pas été utilisé depuis un certain temps, ne sera probablement pas utilisé dans un certain temps également. Cependant, ce n'est pas toujours le cas, et dans des cas exceptionnels, oui, les performances peuvent en souffrir. Plus d'informations à ce sujet 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 un simple pageremplacement, sans déplacer aucun autre processus.

Solution au problème 1: un processus peut accéder à une mémoire illimitée. Lorsque plus de mémoire que disponible est nécessaire, 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(ou page) sont déplacées vers le disque. Cela peut durer indéfiniment, et comme l'espace disque est bon marché et pratiquement illimité, cela donne une illusion de mémoire illimitée. Autre raison du nom Virtual Memory, il vous donne une illusion de mémoire qui n'est pas vraiment disponible!

Cool. Auparavant, nous étions confrontés à un problème où même si un processus réduit en taille, l'espace vide est difficile à récupérer par d'autres processus (car cela nécessiterait un compactage coûteux). Maintenant, c'est facile, lorsqu'un processus devient de plus petite taille, beaucoup de ses pagesprocessus ne sont plus utilisés, donc lorsque d'autres processus ont besoin de plus de mémoire, une simple LRUéviction basée expulse automatiquement ceux qui sont moins utilisés pagesde la RAM et les remplace par les nouvelles pages de les autres processus (et bien sûr la mise à jour page tablesde tous ces processus ainsi que le processus d'origine qui nécessite désormais moins d'espace), le tout sans opération de compactage coûteuse!

Solution au problème 3: chaque fois que les processus réduisent en taille, leur framesRAM sera moins utilisée, donc une simple LRUexpulsion basée peut expulser ces pages et les remplacer pagespar des processus requis par de nouveaux processus, évitant ainsi Internal Fragmentationsans nécessité compaction.

Quant au problème 2, prenez un moment pour le comprendre, le scénario lui-même est complètement supprimé! Il n'est pas nécessaire de déplacer un processus pour s'adapter à un nouveau processus, car maintenant, l'ensemble du processus n'a jamais besoin de s'adapter en même temps, seules certaines pages de celui-ci doivent s'adapter ad hoc, ce qui se produit en expulsant framesde la RAM. Tout se passe en unités de pages, donc il n'y a pas de concept de holemaintenant, et donc pas question de quoi que ce soit en mouvement! Peut-être 10 pagesont dû être déplacés à cause de cette nouvelle exigence, il y en a des milliers pagesqui restent intacts. Alors qu'auparavant, tous les processus (tous les éléments) devaient être déplacés!

Solution au problème 2: pour s'adapter à un nouveau processus, les données des parties les moins récemment utilisées d'autres processus doivent être expulsées selon les besoins, et cela se produit dans des unités de taille fixe appelées pages. Il n'y a donc aucune possibilité de holeou External Fragmentationavec ce système.

Désormais, lorsque le processus doit effectuer une opération d'E / S, il peut facilement abandonner le processeur! Le système d'exploitation expulse simplement tout son pagesde la RAM (peut-être le stocker dans un cache) tandis que de nouveaux processus occupent la RAM entre-temps. Lorsque l'opération d'E / S est terminée, le système d'exploitation les restaure simplement pagesdans la RAM (bien sûr en remplaçant le pagesde certains autres processus, peut provenir de ceux qui ont remplacé le processus d'origine, ou peut provenir de certains qui eux-mêmes doivent faire I / O maintenant, et par conséquent peut abandonner la mémoire!)

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

Et bien sûr, aucun processus n'accède directement à la RAM. Chaque processus accède à un emplacement de mémoire virtuelle, qui est mappé à une adresse RAM physique et maintenu par le page-tablede ce processus. Le mappage est basé sur le système d'exploitation, le système d'exploitation permet au processus de savoir quelle trame est vide afin qu'une nouvelle page pour un processus puisse y être intégrée. Étant donné que cette allocation de mémoire est supervisée par le système d'exploitation lui-même, il peut facilement garantir qu'aucun processus n'empiète sur le contenu d'un autre processus en n'allouant que des images vides de la RAM, ou en empiétant sur le contenu d'un autre processus dans la RAM, communique au processus. pour le mettre à jour page-table.

Solution au problème d'origine: il n'y a aucune possibilité qu'un processus accède au contenu d'un autre processus, car toute l'allocation est gérée par le système d'exploitation lui-même et chaque processus s'exécute dans son propre espace d'adressage virtuel en bac à sable.

Donc paging(entre autres techniques), en conjonction avec la mémoire virtuelle, c'est ce qui alimente les logiciels d'aujourd'hui fonctionnant sur OS-es! Cela libère le développeur du logiciel de 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. Cependant, ce n'est bien sûr pas une preuve complète. Il y a des défauts:

1. Pagingest, en fin de compte, donner à l'utilisateur l'illusion d'une mémoire infinie en utilisant le disque comme sauvegarde secondaire. Récupération des données du stockage secondaire pour les insérer dans la mémoire (appeléepage swap , et l'événement de ne pas trouver la page souhaitée dans la RAM est appelé page fault) est coûteux car il s'agit d'une opération IO. Cela ralentit le processus. Plusieurs échanges de pages de ce type se succèdent et le processus devient extrêmement lent. Avez-vous déjà vu votre logiciel fonctionner correctement et soudainement, il devient si lent qu'il se bloque presque ou ne vous laisse aucune option pour le redémarrer? Il se peut que trop de permutations de pages se produisent, ce qui ralentit (appelé thrashing).

Alors revenons à OP,

Pourquoi avons-nous besoin de la mémoire virtuelle pour exécuter un processus? - Comme la réponse l'explique longuement, donner aux logiciels l'illusion de l'appareil / OS ayant une mémoire infinie, de sorte que n'importe quel logiciel, grand ou petit, puisse être exécuté, sans se soucier de l'allocation de mémoire, ou d'autres processus corrompant ses données, même lorsque fonctionnant en parallèle. C'est un concept, mis en œuvre dans la pratique à travers diverses techniques, dont l'une, comme décrit ici, est pagination . Cela peut aussi être une 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 tient 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 elle, et elle contient le mappage des adresses crachées par cela processus à l'adresse physique réelle dans la RAM. Puisque les adresses crachées par le processus ne sont pas de vraies adresses, 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? - Il est pris en charge par, en tandem, l'OS et le logiciel. Imaginez une fonction dans votre code (qui a finalement été compilée et transformée en l'exécutable qui a engendré le processus) qui contient une variable locale - un int i. Lorsque le code s'exécute, iobtient une adresse mémoire dans la pile de la fonction. Cette fonction est elle-même stockée en tant qu'objet ailleurs. Ces adresses sont générées par le compilateur (le compilateur qui a compilé votre code dans l'exécutable) - adresses virtuelles. Lorsqu'il est exécuté, idoit résider quelque part dans l'adresse physique réelle pendant au moins la durée de cette fonction (à moins qu'il ne s'agisse d'une variable statique!), Donc le système d'exploitation mappe l'adresse virtuelle générée par le compilateur deidans une adresse physique réelle, de sorte que chaque fois que, dans cette fonction, un code nécessite la valeur dei, ce processus peut interroger le système d'exploitation pour cette adresse virtuelle, et le système d'exploitation peut à son tour interroger l'adresse physique pour la valeur stockée et la renvoyer.

Supposons que si la taille de la RAM est 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, sur Windows 32 bits, c'est 16 TB, sur Windows 64 bits, c'est le cas 256 TB. Bien sûr, il est également limité par la taille du disque, car c'est là que la mémoire est sauvegardée.

Je copie sans vergogne les extraits de la page de manuel du haut

VIRT - Image virtuelle (Ko) La quantité totale de mémoire virtuelle utilisée par la tâche. Il comprend tous les codes, données et bibliothèques partagées, ainsi que les pages qui ont été échangées et les pages qui ont été mappées mais non utilisées.

SWAP - Taille permutée (ko) Mémoire non résidente mais présente dans une tâche. Il s'agit de la mémoire qui a été permutée mais qui pourrait inclure de la mémoire non résidente supplémentaire. Cette colonne est calculée en soustrayant la mémoire physique de la mémoire virtuelle

Voir ici: Mémoire physique vs 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 de RAM installées dans l'ordinateur. La mémoire virtuelle est limitée par la taille du disque dur, donc la mémoire virtuelle a la capacité de plus de stockage.