Red Hat Enterprise Linux 3: Introduction à l'administration système | ||
---|---|---|
Précédent | Chapitre 4. Mémoire physique et mémoire virtuelle | Suivant |
Bien que la technologie soutendant la construction des différentes technologies de stockage modernes soit vraiment impressionnante, il n'est pas nécessaire que l'administrateur système moyen en connaisse tous les détails. En fait, il suffit à ces derniers de garder à l'esprit un seul point, à savoir :
la RAM n'est jamais assez grande.
Alors que ce truisme puisse au premier abord paraître humoristique, de nombreux concepteurs de systèmes d'exploitation ont passé énormément de temps à essayer de réduire l'impact de ce manque réel de mémoire. Ils y sont parvenu grâce à la mémoire virtuelle — une manière d'allier de la RAM à un stockage lent, afin de donner à un système une mémoire vive plus grande que celle effectivement installée.
Commençons avec une application hypothétique. Le code de l'ordinateur composant cette application a une taille de 10000 octets. Il a également besoin de 5000 octets pour le stockage de données et les tampons d'E/S. Dans de telles conditions, l'application ne peut fonctionner que si la RAM dispose d'au moins 15000 octets ; même si sa taille est inférieure de juste un octet, l'application ne pourra pas tourner.
On fait référence à ce besoin de 15000 sous le terme d'espace d'adressage d'une application. Il correspond au nombre d'adresses uniques nécessaire pour contenir aussi bien l'application que ses données. Dans les premiers ordinateurs, la quantité de RAM disponible devait être supérieure à l'espace adressage nécessaire pour faire tourner la plus grande application ; dans le cas contraire, l'application échouait et un message d'erreur apparaissait signalant une "mémoire insuffisante".
Une autre approche connue sous le terme d'écrasement (ou overlaying en anglais) a essayer de résoudre le problème en permettant aux programmeurs de spécifier les parties de leur application devant être en mémoire à tout moment donné. De la sorte, un code nécessaire uniquement à des fins d'initialisation pouvait être écrasé (par superposition) par le code utilisé ultérieurement. Alors que ce processus a permis de minimiser l'importance des problèmes de manque de mémoire, sa mise en oeuvre était non seulement complexe mais également source de nombreuses erreurs. De plus, ce processus de superposition n'a pas réussi à résoudre le problème du manque de mémoire au niveau du système entier lors de l'exploitation (runtime). En d'autre termes, il est possible qu'au niveau de son exécution, un programme aux codes superposés nécessite moins de mémoire qu'un progamme qui ne l'est pas ; ceci étant, si le système ne dispose pas d'une mémoire suffisante pour le programme aux codes superposés, le résultat final demeure le même — un message d'erreur signalant une quantité de mémoire insuffisante.
La notion de mémoire virtuelle chamboule quelque peu le concept de l'espace d'adressage d'une application. Au lieu de se concentrer sur la quantité maximale nécessaire au le bon fonctionnement d'une application, un système doté d'une mémoire virtuelle essaie en permanence d'obtenir une réponse à la question inverse "quelle est la quantité minimale de mémoire nécessaire au bon fonctionnement d'une application ?"
Alors qu'au première abord, notre application hypothétique semble avoir besoin de 15000 octets pour fonctionner correctement, revenez un instant à nos propos de la Section 4.1 — l'accès à la mémoire à tendance à s'effectuer de manière séquentielle et localisée. Dans de telles conditions, la quantité de mémoire nécessaire pour exécuter l'application à tout moment donné est inférieure à 15000 octets — et vous comprendrez qu'en fait, une quantité de mémoire inférieure est généralement nécessaire. Prenez par exemple, les types d'accès à la mémoire qui sont nécessaires pour exécuter une instruction sur un seul ordinateur :
La lecture de l'instruction se fait depuis la mémoire.
Les données dont l'instruction a besoin sont lues depuis la mémoire.
Une fois l'instruction exécutée, les résultats de cette dernière sont renvoyés vers la mémoire pour y être enregistrés.
Le nombre spécifique d'octets nécessaire pour chaque accès à la mémoire varie selon l'architecture du CPU, l'instruction elle-même et le type de données. Toutefois, même si une instruction avait besoin de 100 octets de mémoire pour chaque type d'accès à la mémoire, les 300 octets nécessaires sont bien loin du total de 15000 octets requis pour l'espace d'adressage de l'application. S'il existait un moyen d'effectuer un suivi des besoins en mémoire d'une application lors de son exécution, il serait possible de la faire tourner en utilisant moins de mémoire que la quantité spécifiées par l'espace d'adressage.
Une question demeure néanmoins :
Si une partie seulement de l'application est en mémoire à un moment donné, où se trouve le reste ?
La réponse à cette question est courte : le reste de l'application demeure sur le disque. En d'autres termes, le disque sert de mémoire de sauvegarde pour la RAM ; un support de stockage plus lent et plus grand servant de "sauvegarde" pour un support plus rapide et plus petit. Au premier abord, une telle situation pourrait entraîner un très grand problème au niveau de la performance — après tout, les disques durs sont tellement plus lents que la RAM.
Cette remarque est certes valable, mais il est tout à fait possible de maximiser les avantages liés au comportement d'accès séquentiel et localisé des applications afin d'éliminer la plupart des implications négatives associées à l'utilisation des disques durs comme mémoire de sauvegarde. Pour ce faire, le sous-système de mémoire virtuelle est structuré de telle sorte qu'il essaie de garantir le stockage en mémoire des parties de l'application actuellement requises — ou susceptibles de l'être dans le futur proche — seulement pour la durée pendant laquelle ces dernières sont effectivement nécessaires.
À bien des égards, cette situation est semblable à la relation existant entre la cache et la RAM : la transformation d'une petite quantité de stockage rapide et d'une grande quantité de stockage lent en une grande quantité de stockage rapide.
Dans cet état d'esprit, examinons maintenant en détail le processus même.
Précédent | Sommaire | Suivant |
Éventail des options de stockage | Niveau supérieur | Mémoire virtuelle : informations détaillées |