Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux Introduction a l'administration systeme - Concepts �l�mentaires de la m�moire virtuelle

4.3. Concepts �l�mentaires de la m�moire virtuelle

Alors 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 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 parvenus gr�ce � la m�moire virtuelle — une mani�re d'associer de la RAM � un stockage lent, afin de donner � un syst�me une m�moire vive plus grande que celle effectivement install�e.

4.3.1. M�moire virtuelle expliqu�e simplement

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 des 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 octets sous le terme d'espace d'adressage de l'application. Il correspond au nombre d'adresses uniques n�cessaires pour contenir aussi bien l'application que ses donn�es. Dans les tout premiers ordinateurs, la quantit� de RAM disponible devait �tre sup�rieure � l'espace d'adressage n�cessaire pour faire tourner la plus grande application�; dans le cas contraire, l'ex�cution de l'application �tait vou�e � l'�chec et un message d'erreur apparaissait signalant une "quantit� de m�moire insuffisante".

Une autre approche connue sous le terme d'�crasement (ou overlaying en anglais) a essay� 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 une fois seulement pour les t�ches 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 li�s au manque de m�moire, sa mise en oeuvre �tait complexe et donnait lieu � de nombreuses erreurs. De plus, ce processus de superposition n'a pas r�ussi � r�soudre le probl�me du manque de m�moire du syst�me en g�n�ral 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�; mais 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, � savoir 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 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 premier 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 bien souvent largement inf�rieure. 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 envoy�s vers la m�moire pour y �tre enregistr�s.

Le nombre sp�cifique d'octets n�cessaires 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� exig�e 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�?

4.3.2. M�moire auxiliaire — la pierre angulaire de la m�moire virtuelle

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 auxiliaire pour la RAM�; un support de stockage plus lent et plus grand servant de "stockage auxiliaire" 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 auxiliaire. 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 le cache et la RAM�: la combinaison d'une petite quantit� de stockage rapide avec une grande quantit� de stockage lent revient en fait � avoir une grande quantit� de stockage rapide.

Dans cet �tat d'esprit, examinons maintenant en d�tail le processus m�me.

 
 
  Published under the terms of the GNU General Public License Design by Interspire