Il m'est arrivé la même chose sur un projet embarqué.
Cependant je n'ai pas pu le désactiver: il n'y avait alors plus assez de RAM disponible.
L'explication :
Certaines pages mémoires sont partagées par de nombreux processus, mais peuvent être dupliquées à tout moment si l'un d'eux décide d'y écrire.
Le noyau ignore quelles pages vont devoir être dupliquées ; sans overcommit il réserve autant de pages que nécessaires pour le pire des cas, celui où tous les processus décident d'écrire dans ces pages initialement partagées.
Concrètement, si un programme utilisant 64Mo de RAM fait un fork(), sans overcommit, le noyau provisionnera une quantité équivalent, quant bien même le nouveau processus se contenterait de faire un printf("Hello world") puis un exit(), ce qui ne nécessite guère que quelques pages mémoire réellement nouvelles par rapport au processus parent.
Je ne suis pas certain à 100% de cette explication, la réalité est sûrement plus complexe, mais il est vraisemblable que désactiver l'overcommit conduise à réduire la quantité de RAM réellement disponible pour les programmes.
[^] # Re: undefined behaviour
Posté par Alek_Lyon . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 1.
Il m'est arrivé la même chose sur un projet embarqué.
Cependant je n'ai pas pu le désactiver: il n'y avait alors plus assez de RAM disponible.
L'explication :
Certaines pages mémoires sont partagées par de nombreux processus, mais peuvent être dupliquées à tout moment si l'un d'eux décide d'y écrire.
Le noyau ignore quelles pages vont devoir être dupliquées ; sans overcommit il réserve autant de pages que nécessaires pour le pire des cas, celui où tous les processus décident d'écrire dans ces pages initialement partagées.
Concrètement, si un programme utilisant 64Mo de RAM fait un fork(), sans overcommit, le noyau provisionnera une quantité équivalent, quant bien même le nouveau processus se contenterait de faire un printf("Hello world") puis un exit(), ce qui ne nécessite guère que quelques pages mémoire réellement nouvelles par rapport au processus parent.
Je ne suis pas certain à 100% de cette explication, la réalité est sûrement plus complexe, mais il est vraisemblable que désactiver l'overcommit conduise à réduire la quantité de RAM réellement disponible pour les programmes.