limite de mémoire du noyau Linux

J'ai un problème déroutant. J'ai une bibliothèque qui utilise sg pour exécuter des CDB personnalisés. Il y a quelques systèmes qui ont régulièrement des problèmes d'allocation de mémoire dans sg . Habituellement, le pilote sg a une limite stricte d'environ 4 Mo, mais nous le voyons sur ces quelques systèmes avec des demandes de ~ 2,3 Mo. Autrement dit, les CDB se préparent à allouer pour un transfert de 2,3 Mo. Il ne devrait pas y avoir de problème ici: 2.3 <4.0.

Maintenant, le profil de la machine. Il s'agit d'un processeur 64 bits mais exécute CentOS 6.0 32 bits (je ne les ai pas construits et je n'ai rien à voir avec cette décision). La version du noyau pour cette distribution CentOS est 2.6.32. Ils ont 16 Go de RAM.

Voici à quoi ressemble l'utilisation de la mémoire sur le système (cependant, parce que cette erreur se produit pendant les tests automatisés, je n'ai pas encore vérifié si cela reflète l'état lorsque cet errno est renvoyé par sg ).

top - 00:54:46 up 5 days, 22:05,  1 user,  load average: 0.00, 0.01, 0.21
Tasks: 297 total,   1 running, 296 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  15888480k total,  9460408k used,  6428072k free,   258280k buffers
Swap:  4194296k total,        0k used,  4194296k free,  8497424k cached

J'ai trouvé cet article du Linux Journal qui concerne l'allocation de mémoire dans le noyau. L'article est daté mais semble concerner le 2.6 (quelques commentaires sur l'auteur en tête). L'article mentionne que le noyau est limité à environ 1 Go de mémoire (bien qu'il ne soit pas tout à fait clair du texte s'il s'agit de 1 Go chacun pour physique et virtuel ou total). Je me demande si c'est une déclaration exacte pour 2.6.32. En fin de compte, je me demande si ces systèmes atteignent cette limite.

Bien que ce ne soit pas vraiment une réponse à mon problème, je m'interroge sur la véracité de la réclamation pour 2.6.32. Alors, quelle est la limite réelle de mémoire pour le noyau? Cela peut devoir être pris en compte pour le dépannage. N'importe quelles autres suggestions sont les bienvenues. Ce qui rend cela si déroutant, c'est que ces systèmes sont identiques à beaucoup d'autres qui ne présentent pas ce même problème.

La limite de 1 Gio pour la mémoire du noyau Linux dans un système 32 bits est une conséquence de l'adressage 32 bits, et c'est une limite assez stricte. Ce n'est pas impossible de changer, mais c'est là pour une très bonne raison; le changer a des conséquences.

Prenons la machine de retour au début des années 1990, lorsque Linux était en cours de création. À l'époque, nous nous demandions si Linux pouvait fonctionner avec 2 Mo de RAM ou s'il avait vraiment besoin de 4 MiB entiers . Bien sûr, les snobs haut de gamme se moquaient tous de nous, avec leurs serveurs monstres de 16 MiB.

Qu'est-ce que cette petite vignette amusante a à voir avec quoi que ce soit? Dans ce monde, il est facile de prendre des décisions sur la façon de diviser l'espace d'adressage de 4 Gio que vous obtenez à partir d'un adressage 32 bits simple. Certains systèmes d'exploitation viennent de le diviser en deux, traitant le bit supérieur de l'adresse comme le "drapeau du noyau": les adresses 0 à 2 ³¹ -1 avaient le bit supérieur effacé, et étaient pour le code d'espace utilisateur, et les adresses 2 ³¹ à 2 ³² - 1 avait le bit le plus haut et était pour le noyau. Vous pouvez simplement regarder l'adresse et dire: 0x80000000 et plus, c'est l'espace du noyau, sinon c'est l'espace utilisateur.

Alors que la taille de la mémoire du PC montait en flèche vers cette limite de mémoire de 4 Gio, cette simple division 2/2 a commencé à devenir un problème. L'espace utilisateur et l'espace noyau avaient tous deux de bonnes prétentions sur beaucoup de RAM, mais comme notre objectif d'avoir un ordinateur est généralement d'exécuter des programmes utilisateur, plutôt que d'exécuter des noyaux, les systèmes d'exploitation ont commencé à jouer avec la division utilisateur / noyau. La scission 3/1 est un compromis commun.

Quant à votre question sur le physique contre le virtuel, cela n'a pas d'importance. Techniquement parlant, c'est une limite de mémoire virtuelle, mais c'est simplement parce que Linux est un système d'exploitation basé sur une machine virtuelle. L'installation de 32 Gio de RAM physique ne changera rien et n'aidera pas swaponune partition de swap de 32 Gio. Quoi que vous fassiez, un noyau Linux 32 bits ne pourra jamais adresser plus de 4 Gio simultanément.

(Oui, je connais PAE . Maintenant que les systèmes d'exploitation 64 bits prennent enfin le relais, j'espère que nous pourrons commencer à oublier ce méchant hack. Je ne pense pas que cela puisse vous aider dans ce cas de toute façon.)

L'essentiel est que si vous utilisez la limite de VM du noyau de 1 Gio, vous pouvez reconstruire le noyau avec une division 2/2, mais cela a un impact direct sur les programmes de l'espace utilisateur.

64 bits est vraiment la bonne réponse.

Je veux ajouter un peu à l'excellente réponse de Warren Young , car les choses sont en fait pires qu'il ne l'écrit.

L'espace d'adressage du noyau de 1 Go est divisé en deux parties. 128 Mo sont pour vmallocet 896 Mo pour lowmem. Peu importe ce que cela signifie réellement. Lors de l'allocation de mémoire, le code du noyau doit choisir lequel de ces éléments il souhaite. Vous ne pouvez pas simplement obtenir de la mémoire quel que soit le pool ayant de l'espace libre.

Si vous choisissez vmalloc, vous êtes limité à 128 Mo. Maintenant, 1 Go n'a pas l'air si mal ...

Si vous choisissez lowmem, vous êtes limité à 896 Mo. Pas si loin de 1 Go, mais dans ce cas, toutes les allocations sont arrondies à la puissance suivante de 2. Une allocation de 2,3 Mo consomme en fait 4 Mo. De plus, vous ne pouvez pas allouer plus de 4 Mo en un seul appel lors de l'utilisation lowmem.

64 bits est vraiment la bonne réponse.