J'étudie pour RHCSA et je suis confus par une déclaration que j'ai rencontrée dans du matériel de formation:

Il n'y a pas de RAM maximale pratique, car théoriquement, vous pourriez exécuter 128 To de RAM sur RHEL 6. Mais ce n'est qu'une théorie. La RAM maximale prise en charge par Red Hat sur RHEL 6 est de 16 Go sur les systèmes 32 bits et de 2 To sur les systèmes 64 bits.

Quelqu'un peut-il expliquer d'où vient la limite théorique de 128 To? Je suis confus sur la façon dont l'auteur sait que la limite théorique existe si RHEL 6 définit clairement d'autres limites maximales. Est-ce simplement prendre en compte les limites théoriques de l'architecture 64 bits? Ou y a-t-il une autre raison ici?

De la documentation du noyau, dans Documentation/x86/x86_64/mm.txt:

Virtual memory map with 4 level page tables:

0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm

2 ⁴⁷ octets = 128 To

Réponse courte

Chaque processus Linux peut traiter au maximum 128 To de mémoire virtuelle . Cependant, c'est plus que ce que le noyau Linux peut gérer physiquement . Cette limite est donc théorique.

Il a probablement été choisi de façon arbitraire, sur la base d'un scénario d'utilisation supposé "pire des cas".

Réponse élaborée

Vous ne pouvez pas réellement utiliser plus de RAM que votre matériel ne le permet (48 bits = 256 To sont courants de nos jours), et vous serez alors limité par la quantité de mémoire physique que le noyau Linux peut gérer.

Par exemple, sur l' architecture Intel x86 64 bits , Linux ne peut pas utiliser plus de 64 To de mémoire physique (depuis la version 2.6.30 , mais c'était 16 To juste avant). Notez que RHEL 6 utilise un noyau 2.6.32 .

Sur l' architecture s390 64 bits , la même limite s'applique (depuis 2.6.28 ). Si vous utilisez 32 bits cependant, la limite est de 4 Go , mais en utilisant une étrange astuce appelée PAE , vous pouvez aller jusqu'à 64 Go (souvent utilisé sur x86).

Je pense que d'autres architectures 64 bits ont des limites inférieures.

Voir le tableau des limites de Red Hat pour plus d'informations (merci Huygens ).

Il ne faut pas mélanger la mémoire virtuelle et la mémoire physique volatile. Le premier est spécifique à l'architecture du processeur et sera mappé sur la mémoire volatile et non volatile. Ce dernier, alias RAM, devrait être indépendant de l'architecture CPU du point de vue du noyau.

L'implémentation AMD et Intel x86_64 d'aujourd'hui ne prend en charge que 48 bits de mémoire virtuelle adressable. Ce qui signifie que le noyau peut adresser 2 ^ 48 = 256 TiB par VM de processus.
Le noyau Linux sur l'architecture x86_64 a divisé l'espace VM adressable en 2, 128 TiB pour l'espace utilisateur et 128 TiB pour l'espace du noyau. Ainsi, un processus peut théoriquement adresser un total de 128 TiB de mémoire virtuelle.

Le maximum de mémoire physique volatile que le noyau peut gérer est un aspect différent, mais je ne connais pas ces informations.

Concernant la déclaration de l'auteur RHCSA

L'auteur de la déclaration "Il n'y a pas de RAM maximale pratique, car théoriquement, vous pouvez exécuter 128 To de RAM sur RHEL 6." utilise une terminologie erronée ou mal comprise. Voici le tableau du site Web de Red Hat résumant les capacités de RHEL 3, 4, 5 et 6 . Et ils indiquent clairement "Espace d'adressage virtuel x86_64 maximum par processus [...] 128 To [pour RHEL 6]"

La même page indique que RHEL 6 prend en charge un maximum de 2 To / 64 To de RAM (mémoire physique volatile). Je suppose que cela signifie qu'il est certifié pour une RAM maximale de 2 To, et pourrait théoriquement aller jusqu'à 64 To. SLES est beaucoup plus clair à cet égard .

L'autre raison pour laquelle il est théorique est le manque d'expérience de mise en œuvre.

Il est courant pour les programmeurs de dimensionner les variables bien à l'avance de ce dont le matériel est capable, de sorte que le noyau n'a pas besoin d'une programmation rip-and-replace risquée car le matériel de cette capacité apparaît une décennie ou plus plus tard.

Cependant, la taille variable n'est pas la seule limite. Les structures de données et leurs algorithmes imposent leurs propres limites. Imaginez un instant faire une marche linéaire d'une structure de données décrivant chaque page de 4 Ko de ces 128 To. Il y a des réponses évidentes: n'utilisez pas de pages de 4 Ko, n'utilisez pas de structure de données linéaire, n'accédez pas souvent à ces structures de données, déchargez autant que possible dans le matériel. Mais il y a une structure de données plus subtile + des limitations d'algorithme que nous ne saurons pas jusqu'à ce que nous les rencontrions.

Nous savons que si nous devions découvrir par magie un PC de 128 To demain et essayer de démarrer Linux dessus, il fonctionnera terriblement, et peut-être si terriblement qu'il ne démarrera pas. Mais la fixation des algorithmes est triviale, la fixation des structures de données est un travail mais encore beaucoup moins de travail que la fixation de la taille d'une variable largement comprise. Nous verrons donc des changements de cette nature à mesure que la taille de la mémoire augmente.