Quels processeurs prennent en charge les pages de 1 Go?

Certains processeurs Intel prennent en charge des pages de 1 Go. Ceci est identifié en regardant CPUID 0x80000001, bit EDX 26 . Le noyau Linux expose cela via /proc/cpuinfocomme pdpe1gbindicateur .

Où pouvons-nous savoir quels processeurs prennent en charge cela et lesquels ne le font pas? Ou quelle gamme de produits prend en charge cette fonctionnalité? Il n'y a rien sur ces pages Intel ARK qui indique la prise en charge de cette fonctionnalité.

Processeurs qui font support pages: 1 Go

Xeon E5620 (Westmere)
Core i5-4250U ( Haswell, Mobile )

Autres processeurs qui ne prennent pas en charge les pages de 1 Go:

Xeon E5506 (Nehalem)
Core i7-2720QM (Sandy Bridge, Mobile)
Core i5-2500K (Sandy Bridge)

cpu

— Jonathon Reinhart
source

Connexes: Comment utiliser les pages Intel Westmere 1 Go sur Linux?

— Jonathon Reinhart

Selon cette page :

en plus de leurs pages standard de 4 Ko, les processeurs x86-64 plus récents, tels que les nouveaux processeurs AMD64 d'AMD et les processeurs Westmere et ultérieurs d'Intel, peuvent utiliser des pages de 1 Go en mode long.

Semble être vrai car c'était une nouvelle fonctionnalité des processeurs Westmere .

— Viacheslav Rodionov
source

Oui, j'ai certainement regardé toutes ces pages Wikipédia! Cependant, cette réponse n'est pas correcte. Sandy Bridge est plus récent que Westmere, et j'ai maintenant deux CPU Sandy Bridge qui ne le prennent pas en charge.

— Jonathon Reinhart

@JonathonReinhart: l' énorme inconvénient des Hugepages à usage général, en particulier. Les pages 1G, c'est que l'énorme page entière consomme autant de RAM physique. Si un processus alloue 1GiB normalement, seules les parties qu'il a touchées prennent réellement de la mémoire virtuelle. (le sur-engagement permet même des allocations que le noyau n'a pas assez d'espace de swap pour gérer). Linux ne peut pas paginer des pages géantes sur le disque même lorsqu'un processus est arrêté, donc une allocation de pages géantes épingle / verrouille efficacement autant de mémoire physique.

— Peter Cordes

2M hugepages de sens quand ils ne seront pas laissés à moitié vide (par exemple , lorsque vous êtes sûr que vous êtes allez écrire tous les 4k de 2M de toute façon), mais le manque de pagination est une grosse affaire. Concevoir un logiciel à usage général pour fonctionner horriblement mal sur des postes de travail à mémoire limitée n'est pas une bonne idée. Je ne pense pas que vous puissiez même mmapper un fichier sur le disque avec des pages gigantesques de 2M, mais ce serait une mauvaise idée pour les exécutables car il y aura quelques pages de 4k dans un bloc de 2M qui ne seront pas touchées. Ceux-ci peuvent être expulsés de la pagecache (en supposant qu'ils aient été prélus), libérant de la RAM.

— Peter Cordes

Avec les processeurs actuels ayant des TLB à plusieurs niveaux, le temps total consacré aux échecs TLB n'est probablement pas trop mauvais, n'est-ce pas? Je n'ai pas profilé de gros trucs comme Firefox. Je serais intéressé de voir un résumé lisible du temps qu'il passe sur les échecs TLB, (en particulier les pages-promenades), et des trucs comme les échecs de cache I L1. Je sais que je pourrais simplement le signaler perf... Même si vous vouliez utiliser d'énormes pages 2M pour Firefox, je suppose que beaucoup de ses données internes sont allouées en plus petits morceaux que cela. Il y aurait des frais généraux pour vous assurer de minimiser la fragmentation externe des allocations à l'intérieur d'un tampon de page énorme.

— Peter Cordes

Les échecs TLB coûtent cher sur les opérations à accès aléatoire à haute mémoire, telles que de nombreuses applications de base de données. Les pages énormes font une différence significative - mais même là, elles parlent de pages de 2 Mo, pas de 1 Go. Le système d'exploitation est l'utilisateur le plus probable des pages de 1 Go grâce au mappage direct de tout l'espace d'adressage physique.

— GreenReaper