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 (c.-à-d. 2 ^ 32-1 espaces d’adressage) quelle est la taille de la mémoire virtuelle?

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 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 de pages, entre autres structures de données pour gérer les mappages. Les mappages de mémoire virtuelle se trouvent toujours dans la table de 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 de pages”). La table de pages est également dans la mémoire physique – souvent dans des espaces réservés au kernel que les programmes utilisateur ne peuvent pas écrire.

La mémoire virtuelle est généralement plus grande que la mémoire physique – il n’y aurait pas de raison de mapper la 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 dans la 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 me tromper ici, mais je parierais que les choses que vous trouvez difficiles à comprendre concernent les implémentations spécifiques de la mémoire virtuelle, probablement la pagination. Il n’y a pas une seule façon de faire de la pagination – il y a beaucoup d’implémentations et celle que décrit votre manuel n’est probablement pas la même que celle qui apparaît dans les vrais OS 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 vaut mieux laisser la question à un autre cibler spécifiquement ce sujet.

Les logiciels fonctionnent sur le système d’exploitation sur une base 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 requirejse peut varier – certains logiciels ont besoin de beaucoup de mémoire, 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 coûteuse (et que la taille du périphérique 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 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 fonctionne toujours jusqu’à ce que l’utilisateur l’abandonne, c’est-à-dire qu’il ne doit pas s’abandonner automatiquement car le système d’exploitation est à court de mémoire.
  2. L’activité ci-dessus, tout en maintenant une performance respectable pour les logiciels en cours d’exécution.

Maintenant, la question principale se résume à la manière dont la mémoire est gérée. Qu’est-ce qui régit exactement où, en mémoire, résident les données appartenant à un logiciel donné?

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 , 1024 octets à l’emplacement 1023 ), soit 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 est pré-assignée à un emplacement mémoire. Ainsi, une fois installée et exécutée, elle stocke simplement ses données dans cette zone de mémoire et tout fonctionne correctement.

Désavantages:

  1. Cela ne s’adapte pas. Théoriquement, une application peut nécessiter une grande quantité de mémoire lorsqu’elle fait quelque chose de très lourd. Ainsi, pour s’assurer qu’il ne manque jamais de mémoire, la zone de mémoire qui lui est allouée doit toujours être supérieure ou égale à cette quantité de mémoire. Que se passe-t-il si un logiciel, dont la mémoire théorique maximale utilisée est de 2 GB (nécessitant une allocation de mémoire de 2 GB ), est installé sur une machine avec seulement 1 GB mémoire? Le logiciel devrait-il abandonner au démarrage, en indiquant que la RAM disponible est inférieure à 2 GB ? Ou devrait-il continuer, et au moment où la mémoire requirejse dépasse 2 GB , abandonner et renvoyer avec le message que la mémoire est insuffisante?

  2. Il n’est pas possible d’empêcher la perte de mémoire. Il existe des millions de logiciels, même si chacun d’eux ne dispose que d’ 1 kB mémoire de 1 kB , la mémoire totale requirejse dépasserait 16 GB , soit plus que la plupart des appareils. Comment, alors, différents logiciels peuvent-ils se voir atsortingbuer des emplacements mémoire qui n’empiètent pas sur leurs zones respectives? Tout d’abord, il n’existe pas de marché de logiciels centralisé capable de réguler la sortie d’un nouveau logiciel, mais il doit pouvoir s’atsortingbuer autant de mémoire à ce domaine encore inoccupé , et deuxièmement, même s’il y en a, il est impossible de le faire. non. des logiciels sont pratiquement infinis (ce qui nécessite une mémoire infinie pour tous les gérer), et la quantité totale de RAM disponible sur n’importe quel périphérique ne suffit pas à accueillir une fraction de ce qui est nécessaire, ce qui rend inévitable sur celle d’un autre. Que se passe-t-il lorsque Photoshop se voit atsortingbuer des emplacements mémoire 1 à 1023 et que VLC se voit atsortingbuer 1000 à 1676 ? Que se passe-t-il si Photoshop stocke des données à l’emplacement 1008 , puis VLC écrase celles qui contiennent ses propres données, puis plus tard Photoshop accédant à l’impression que les mêmes données ont été stockées auparavant? Comme vous pouvez l’imaginer, de mauvaises choses vont arriver.

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

Solution possible 2 : Essayons un autre schéma – où l’OS fera la majorité de la gestion de la mémoire. Les logiciels, quand ils ont besoin de mémoire, demandent simplement le système d’exploitation, et le système d’exploitation s’adaptera en conséquence. Dire OS garantit que 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 dit précédemment, la RAM peut être imaginée comme un tableau linéaire d’octets, pour un octet compris entre 0 et 2^32-1 ) si le processus est en cours, sinon s’il s’agit d’un processus en cours 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ù les données seront stockées, le système d’exploitation devra conserver un mappage, par logiciel, de l’adresse émise par le logiciel à l’adresse physique réelle (Remarque: c’est l’une des deux raisons que nous appelons ce concept Virtual Memory : les logiciels ne se soucient pas de la véritable adresse mémoire où leurs données sont stockées, ils ne font que cracher des adresses à la volée et le système d’exploitation trouve le bon emplacement le trouver plus tard si nécessaire).

Supposons que le périphérique vient d’être allumé, que le système d’exploitation vient de démarrer, et qu’il n’existe pas d’autre processus en cours (en ignorant le système d’exploitation, qui est également un processus!), Et vous décidez de lancer VLC . Ainsi, VLC se voit atsortingbuer une partie de la RAM à partir des adresses d’octets les plus basses. Bien. Maintenant 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 Notepad pour griffonner du texte. Et puis Eclipse pour faire du codage. Bientôt, votre mémoire de 4 GB est 4 GB et la RAM ressemble à ceci:

entrer la description de l'image ici

Problème 1: Vous ne pouvez plus démarrer aucun autre processus, car toute la mémoire vive est épuisée. Ainsi, les programmes doivent être écrits en gardant à l’esprit la mémoire disponible maximale (pratiquement moins seront disponibles, car les 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 PC délabré de 1 GB .

Bon, 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 à ceci maintenant:

entrer la description de l'image ici

Supposons que ces deux libère 700 MB espace – ( 400 + 300 ) Mo. Maintenant, vous devez lancer Opera , qui occupera 450 MB espace. Eh bien, vous avez plus de 450 MB espace disponible au total, mais … ce n’est pas contigu, il est divisé en morceaux individuels, dont aucun n’est assez grand pour contenir 450 MB Donc, vous obtenez une idée géniale, déplaçons tous les processus ci-dessous au maximum, ce qui laissera un espace vide de 700 MB dans un morceau en bas. Cela s’appelle le compaction . Génial, sauf que … tous les processus qui existent sont en cours d’exécution. Les déplacer signifie déplacer l’adresse de tout leur contenu (rappelez-vous, OS maintient un mappage de la mémoire crachée par le logiciel sur l’adresse mémoire réelle. Le logiciel Imagine a craché une adresse de 45 avec les données 123 et le système d’exploitation l’a stocké) dans l’emplacement 2012 et créé une entrée dans la carte, mappant de 45 à 2012 Si le logiciel est maintenant déplacé dans la mémoire, ce qui était auparavant à l’emplacement 2012 ne le sera plus en 2012 , mais dans un nouvel emplacement, et le système d’exploitation doit mettre à jour la carte correspondant à la nouvelle adresse, de sorte que le logiciel puisse obtenir les données attendues ( 123 ) lorsqu’il interroge l’emplacement de mémoire 45 En ce qui concerne le logiciel, tout ce qu’il sait, c’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ù on y accède à nouveau, son adresse a changé et il ne pourra plus le trouver. La même chose sera valable pour toutes les fonctions, objects, variables. En gros, tout a une adresse, et déplacer un processus signifie changer l’adresse de chacun. Ce qui nous amène à:

Problème 2: Vous ne pouvez pas déplacer un processus. Les valeurs de toutes les variables, fonctions et objects de ce processus ont des valeurs codées en dur par le compilateur lors de la compilation, le processus dépend de leur emplacement au cours de leur durée de vie et leur modification est coûteuse. En conséquence, les processus laissent de grands ” holes ” lorsqu’ils sortent. Cela s’appelle External Fragmentation .

Bien. Supposons que, d’une manière miraculeuse, vous réussissiez à faire avancer les processus. Maintenant, il y a 700 MB d’espace libre en bas:

entrer la description de l'image ici

Opera s’intègre parfaitement dans le bas. Maintenant, votre RAM ressemble à ceci:

entrer la description de l'image ici

Bien. Tout va bien. Cependant, il ne rest plus beaucoup d’espace, et vous devez maintenant relancer Chrome , un système de mémoire connu! Il faut beaucoup de mémoire pour commencer, et il ne vous en rest presque plus … Sauf que vous remarquez que certains des processus, qui occupaient initialement un grand espace, n’ont plus besoin de beaucoup d’espace. Peut-être vous avez arrêté votre vidéo dans VLC , par conséquent, il occupe encore 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 Notepad et Photos . Votre RAM ressemble maintenant à ceci:

entrer la description de l'image ici

Holes , encore une fois! Retour à la case départ! Sauf que précédemment, les trous étaient dus à des processus se terminant, maintenant c’est dû à des processus nécessitant moins d’espace qu’auparavant! Et vous avez encore le même problème, les holes combinés donnent plus d’espace que nécessaire, mais ils sont dispersés, ce qui n’est pas très utile. Il faut donc déplacer à nouveau ces processus, une opération coûteuse et très fréquente, car la taille des processus est souvent réduite 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 de l’espace inutilisé, ce qui nécessitera, si nécessaire, l’opération coûteuse de déplacement de nombreux processus. Cela s’appelle la Internal Fragmentation .

Bon, maintenant, votre système d’exploitation fait le nécessaire, déplace les processus et lance Chrome, et après un certain temps, votre RAM ressemble à ceci:

entrer la description de l'image ici

Cool. Supposons maintenant que vous repreniez la lecture d’ Avatar dans VLC . Son besoin de mémoire va exploser! Mais … il ne rest plus d’espace pour se développer, car le Blocnotes est blotti au fond. Donc, encore une fois, tous les processus doivent évoluer jusqu’à ce que VLC ait trouvé suffisamment d’espace!

Problème 4: Si les processus doivent croître, l’opération sera très coûteuse

Bien. Maintenant, supposons que Photos est utilisé pour charger des photos à partir d’un disque dur externe. L’access au disque dur vous emmène du domaine des caches et de la RAM à celui du disque, qui est plus lent par ordre de grandeur. Douloureusement, irrévocablement, plus lentement transcendantalement. C’est une opération d’E / S, ce qui signifie qu’il n’est pas lié au CPU (c’est plutôt l’exact opposé), ce qui signifie qu’il n’a pas besoin d’occuper la RAM pour le moment. Cependant, il occupe toujours obstinément la RAM. 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 retiré de la mémoire pendant toute la durée de son activité liée aux E / S, cela libérerait beaucoup de mémoire, suivi par un compactage (coûteux), suivi par Firefox .

Problème 5: Les travaux liés aux E / S continuent d’occuper la RAM, entraînant une sous-utilisation de la RAM, qui aurait pu être utilisée entre-temps par les travaux liés à la CPU.

Comme nous pouvons le constater, nous avons beaucoup de problèmes, même avec l’approche de la mémoire virtuelle.


Il existe deux approches pour résoudre ces problèmes – la paging et la segmentation . Parlons de la paging . Dans cette approche, l’espace d’adressage virtuel d’un processus est mappé sur la mémoire physique en morceaux, appelés pages . Une taille de page typique est de 4 kB . Le mappage est maintenu par quelque chose appelé une page table , étant donné une adresse virtuelle, il suffit maintenant de trouver à quelle page appartient l’adresse, puis à partir de la page table , de trouver l’emplacement correspondant dans la mémoire physique réelle ( connu sous le nom de frame ), et étant donné que le décalage de l’adresse virtuelle dans la page est le même pour la page et le frame , recherchez l’adresse réelle en ajoutant ce décalage à l’adresse renvoyée par la page table . Par exemple:

entrer la description de l'image ici

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 à un emplacement à droite, et nous aurions été si heureux. Mais comme la malchance le veut, 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! Bon, voyons comment on se débrouille avec ça.

Lorsque le processus démarre, une demande d’access à la mémoire pour l’emplacement 35 est effectuée. Ici, la taille de la page est de 8 (chaque page contient 8 emplacements, l’espace d’adresse virtuel complet de 40 emplacements contient donc 5 pages). Donc, cet endroit appartient à la page no. 4 ( 35/8 ). Dans cette page , cet emplacement a un décalage de 5 ( 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. Ainsi, la page table , qui maintient une correspondance entre les pages de gauche et les pages réelles à droite (où elles sont appelées frames ), 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 le numéro de page. 4 pour ce processus (essentiellement un bloc mémoire du programme sur le disque dont les adresses vont de 32 à 39 ). Lorsqu’il arrive, le système d’exploitation alloue la page quelque part dans la RAM, par exemple la première image, et la page table pour ce processus prend note que la page 4 correspond à l’image 0 de la RAM. Maintenant, les données sont enfin là dans la mémoire physique. OS interroge à nouveau la table de pages pour le tuple (4,3) , et cette fois, la table de pages indique que la page 4 est déjà mappée à l’image 0 dans la RAM. Donc, le système d’exploitation va simplement à la 0ème image de la RAM, accède aux données à l’offset 3 dans cette image (Prenez un moment pour comprendre cela. La page entière, qui a été extraite du disque, est déplacée sur frame . L’emplacement de mémoire individuel dans une page était, il sera également identique dans le cadre, puisque dans la page / le frame , l’unité de mémoire réside toujours au même endroit!), et renvoie les données! Les données n’étant pas présentes dans la mémoire lors de la première requête, mais plutôt sur le disque pour être chargées en mémoire, elles constituent un échec .

Bien. Supposons maintenant qu’un access mémoire pour l’emplacement 28 soit effectué. Cela se résume à (3,4) . Page table ne comporte actuellement qu’une seule entrée, mappant la page 4 à l’image 0 . Donc c’est encore un échec , le processus abandonne le CPU, le pilote de périphérique récupère la page du disque, le processus reprend le contrôle du CPU et sa page table est mise à jour. Dites maintenant que la page 3 est mappée à l’image 1 de la RAM. Donc, (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 access à la mémoire concerne l’emplacement 8 , qui se traduit par (1,0) . La page 1 n’est pas encore en mémoire, la même procédure est répétée et la page est allouée à l’image 2 de la RAM. Maintenant, le mappage de processus RAM ressemble à l’image ci-dessus. À ce stade, la RAM, qui ne dispose que de 24 unités de mémoire, est remplie. Supposons que la prochaine demande d’access à la mémoire pour ce processus provient de l’adresse 30 . Elle correspond à (3,6) et la page table indique que la page 3 trouve dans la RAM et correspond à l’image 1 . Yay! Ainsi, les données sont extraites de l’emplacement RAM (1,6) et renvoyées. Cela constitue un succès , car les données requirejses peuvent être obtenues directement à partir de la RAM, ce qui est très rapide. De même, les quelques demandes d’access suivantes, par exemple pour les emplacements 11 , 32 , 26 , 27 , sont toutes des hits , c’est-à-dire que les données demandées par le processus se trouvent directement dans la RAM sans avoir à chercher ailleurs.

Supposons maintenant qu’une requête d’access à la mémoire pour l’emplacement 3 vienne. Il se traduit par (0,3) , et la page table pour ce processus, qui a actuellement 3 entrées, pour les pages 1 , 3 et 4 indique que cette page n’est pas en mémoire. Comme dans les cas précédents, il est extrait du disque, mais contrairement aux cas précédents, la RAM est remplie! Alors que faire maintenant? Ici réside la beauté de la mémoire virtuelle, un cadre de la mémoire vive est expulsé! (Différents facteurs déterminent quelle base doit être expulsée. Il peut s’agir d’une base LRU , où la trame la plus récemment consultée pour un processus doit être expulsée. Il peut s’agir de la first-cum-first-evicted base de first-cum-first-evicted , où la trame atsortingbuée il y a plus longtemps, est expulsé, etc.) Donc, certaines images sont expulsées. Dites le cadre 1 (en le choisissant au hasard). Cependant, cette frame est mappée sur une page ! (Actuellement, il est associé à la table de pages de notre seul et unique processus à partir de la page 4 ). Donc, ce processus doit être raconté cette tragique nouvelle, à savoir qu’un seul frame , qui vous appartient malheur, doit être expulsé de RAM pour faire place à d’autres pages . Le processus doit s’assurer qu’il met à jour sa page table avec ces informations, c’est-à-dire en supprimant l’entrée pour ce duo de cadre de page, de sorte que la prochaine demande de cette page indique que cette page est plus en mémoire, et doit être récupéré à partir du disque. Bien. Ainsi, la trame 1 est expulsée, la page 0 est introduite et placée dans la RAM, et l’entrée de la page 4 est supprimée et remplacée par la correspondance de la page 0 avec la même image 1 . Alors maintenant, notre mapping ressemble à ceci (notez le changement de couleur dans le deuxième frame à droite):

entrer la description de l'image ici

Vu ce qui vient de se passer? Le processus devait prendre de l’ampleur, 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 être déplacé pour s’adapter à un processus croissant, il était remplacé par une seule page ! Cela a été rendu possible par le fait que la mémoire d’un processus n’a plus besoin d’être contiguë, qu’il peut résider à différents endroits dans les blocs, que le système d’exploitation conserve les informations sur leur emplacement et qu’il est requirejs. Remarque: vous pensez peut-être, hein, si la plupart du temps c’est un miss , et que les données doivent être constamment chargées depuis le disque vers la mémoire? Oui, théoriquement, c’est possible, mais la plupart des compilateurs sont conçus de manière à suivre la locality of reference , c.-à-d. Si des données provenant d’un emplacement de mémoire sont utilisées, les prochaines données nécessaires se trouveront la page qui vient d’être chargée en mémoire. En conséquence, le prochain échec se produira après un certain temps, la plupart des besoins en mémoire à venir seront satisfaits par la page que vous venez d’apporter, ou les pages déjà en mémoire qui ont été récemment utilisées. Le même principe exact nous permet également d’expulser la page la moins récemment utilisée, avec la logique que ce qui n’a pas été utilisé depuis un certain temps ne sera probablement pas utilisé depuis longtemps. Cependant, ce n’est pas toujours le cas et, dans des cas exceptionnels, oui, la performance peut en souffrir. En savoir plus plus tard.

Solution au problème 4: Les processus peuvent maintenant évoluer facilement, si un problème d’espace est rencontré, il suffit de faire un simple remplacement de page , 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é en tant que sauvegarde, les nouvelles données requirejses sont chargées en mémoire à partir du disque et le bloc de données (ou la page ) le moins récemment utilisé est déplacé sur le disque. Cela peut durer indéfiniment, et comme l’espace disque est bon marché et quasiment 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 la taille d’un processus était réduite, l’espace vide était difficile à récupérer par d’autres processus (car cela nécessiterait un compactage coûteux). Maintenant, c’est facile, quand un processus devient plus petit, beaucoup de ses pages ne sont plus utilisées, alors quand d’autres processus ont besoin de plus de mémoire, une simple expulsion basée sur LRU expulse automatiquement ces pages moins utilisées et les remplace par de nouvelles pages des autres processus (et bien sûr la mise à jour des page tables de page tables de tous ces processus, ainsi que le processus original qui nécessite désormais moins d’espace), le tout sans opération de compactage coûteuse!

Solution au problème n ° 3: chaque fois que les processus sont réduits, leurs frames en RAM seront moins utilisés, de sorte qu’une simple éviction basée sur LRU peut expulser ces pages et les remplacer par les pages requirejses par les nouveaux processus, évitant ainsi la compaction Internal Fragmentation .

Quant au problème 2, prenez un moment pour comprendre cela, le scénario lui-même est complètement supprimé! Il n’est pas nécessaire de déplacer un processus pour l’adapter à un nouveau processus, car le processus complet n’a désormais plus besoin d’être ajusté, seules certaines pages doivent s’adapter au cas par cas, en expulsant des 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 plus question de bouger! Peut-être que 10 pages ont dû être déplacées en raison de cette nouvelle exigence, il y a des milliers de pages qui ne sont pas touchées. Alors que plus tôt, tous les processus (tous les bits) devaient être déplacés!

Solution au problème n ° 2: pour s’adapter à un nouveau processus, les données provenant de parties moins utilisées d’autres processus doivent être expulsées si nécessaire, et cela dans des unités de taille fixe appelées pages . Il n’y a donc aucune possibilité de hole ou de External Fragmentation avec ce système.

Maintenant, lorsque le processus doit effectuer des opérations d’E / S, il peut facilement abandonner le processeur! OS écarte simplement toutes ses pages de la RAM (peut-être le stocke dans un cache) alors que de nouveaux processus occupent la RAM entre-temps. Une fois l’opération d’E / S terminée, le système d’exploitation restaure simplement ces pages dans la mémoire vive (bien sûr, en remplaçant les pages de certains autres processus, il peut s’agir de celles qui ont remplacé le processus d’origine). I / O maintenant, et donc 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 utilisation correcte de la mémoire vive.

Et bien sûr, maintenant aucun processus n’accède directement à la RAM. Chaque processus accède à un emplacement de mémoire virtuelle, qui est mappé sur une adresse de RAM physique et géré par la page-table de page-table de ce processus. Le mappage est sauvegardé par le système d’exploitation, le système d’exploitation permet au processus de savoir quelle image est vide afin qu’une nouvelle page de processus puisse y être intégrée. Comme cette allocation de mémoire est surveillée par le système d’exploitation lui-même, elle peut facilement garantir qu’aucun processus n’empiète sur le contenu d’un autre processus en allouant uniquement des images vides à la mémoire. pour le mettre à jour.

Solution au problème d’origine: il est impossible qu’un processus accède au contenu d’un autre processus, car la totalité de 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 mode bac à sable.

Ainsi, la paging (entre autres techniques), associée à la mémoire virtuelle, est ce qui fait fonctionner les logiciels fonctionnant sous OS-es! Cela évite au développeur de logiciels de s’inquiéter de la quantité de mémoire disponible sur le périphérique de l’utilisateur, de l’endroit où stocker les données, d’empêcher les autres processus de corrompre les données de leur logiciel, etc. Il y a des défauts:

  1. Paging donne finalement à 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 adapter à la mémoire (appelée page swap et le fait de ne pas trouver la page souhaitée dans la mémoire RAM est appelée page fault ) est coûteuse 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? Peut-être que trop de échanges de pages ont eu lieu, le rendant lent (appelé « thrashing ).

Donc, revenir à OP,

Pourquoi avons-nous besoin de la mémoire virtuelle pour exécuter un processus? – Comme l’explique longuement la réponse, donner aux logiciels l’illusion que le périphérique / système d’exploitation dispose d’une mémoire infinie, de sorte que tout logiciel, petit ou grand, puisse être exécuté sans se soucier de l’allocation de mémoire ou d’autres processus corrompant ses données. en parallèle. C’est un concept, mis en œuvre dans la pratique par différentes techniques, dont l’une, décrite ici, est la pagination . Il peut également s’agir d’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 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 et contient le mappage des adresses traiter à l’adresse physique réelle dans la RAM. Comme les adresses crachées par le processus ne sont pas de véritables adresses, elles sont, en un sens, 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, en tandem, par l’OS et le logiciel. Imaginez une fonction dans votre code (qui a finalement été compilée et transformée en exécutable qui a généré le processus) et qui contient une variable locale – un int i . Lorsque le code s’exécute, i reçois une adresse mémoire dans la stack de la fonction. Cette fonction est elle-même stockée en tant qu’object ailleurs. Ces adresses sont générées par le compilateur (le compilateur qui a compilé votre code dans l’exécutable) – les adresses virtuelles. Lorsqu’elle est exécutée, i dois résider quelque part dans une adresse physique réelle pour la durée de cette fonction (sauf s’il s’agit d’une variable statique!). Par conséquent, l’OS mappe l’adresse virtuelle générée par le compilateur sur une adresse physique réelle. cette fonction, un code nécessite la valeur de i , 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 de la valeur stockée et la renvoyer.

Supposons que si la taille de la RAM est de 4 Go (c.-à-d. 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, cela dépend du système d’exploitation. Par exemple, sur Windows 32 bits, il fait 16 TB , sur Windows 64 bits, il est de 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 de top

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

SWAP – Taille permutée (kb) Mémoire non résidente mais présente dans une tâche. C’est de la mémoire qui a été remplacé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: Physical Vs Virtual Memory

La mémoire virtuelle est stockée sur le disque dur et est utilisée lorsque la mémoire vive est remplie. La mémoire physique est limitée à la taille des puces de mémoire vive installées sur l’ordinateur. La mémoire virtuelle est limitée par la taille du disque dur, de sorte que la mémoire virtuelle offre davantage de capacité de stockage.