Dans les systèmes modernes, aucune partie de la mémoire n'est réellement copiée simplement parce qu'un appel système fork est utilisé. Tout est marqué en lecture seule dans la table des pages, de sorte que lors de la première tentative d'écriture, un piège dans le code du noyau se produira. Ce n'est qu'une fois la première tentative d'écriture du processus que la copie aura lieu.
C'est ce qu'on appelle la copie sur écriture.
Cependant, il peut être nécessaire de suivre également l'espace d'adressage engagé. Si aucune mémoire ou swap n'est disponible au moment où le noyau doit copier une page, il doit tuer un processus pour libérer de la mémoire. Ce n'est pas toujours souhaitable, il est donc possible de garder une trace de la quantité de mémoire sur laquelle le noyau s'est engagé.
Si le noyau s'engage sur plus que la mémoire disponible + swap, il peut donner un code d'erreur lors de la tentative d'appel de fork. S'il y en a suffisamment, le noyau validera la taille virtuelle complète du parent pour les deux processus après le fork.
Ne vous inquiétez pas, cela fait une copie paresseuse (copie sur écriture). Les adresses de mémoire virtuelle des deux processus pointent initialement vers les mêmes pages, mais lorsque le processus dupliqué essaie de le modifier, il fait en fait une copie physique de la page (à partir de là, cette page réside à deux endroits dans votre RAM).
Attention, aucune des empreintes mémoire signalées ne vous indique réellement la quantité de RAM utilisée par le processus. En raison de l'échange, du partage de mémoire et d'autres problèmes liés à la mémoire virtuelle, il est impossible de le savoir avec certitude. Certaines parties de l'espace mémoire sont des bibliothèques partagées (où les compter ?), certaines font référence à de la mémoire non RAM (autres périphériques matériels), certaines sont actuellement échangées, certaines ne sont pas encore copiées (copie sur écriture) et bientôt. Lisez ceci :
https://lwn.net/Articles/642202/
Il y a un réglage du noyau
/proc/sys/vm/overcommit_memory
Citation d'un excellent article :
Since 2.5.30 the values are: 0 (default): as before: guess about how much
overcommitment is reasonable, 1: never refuse any malloc(), 2: be precise
about the overcommit - never commit a virtual address space larger than swap
space plus a fraction overcommit_ratio of the physical memory. Here
/proc/sys/vm/overcommit_ratio (by default 50) is another user-settable
parameter. It is possible to set overcommit_ratio to values larger than 100.
(See also Documentation/vm/overcommit-accounting.)
Cela s'applique aux fourches ainsi qu'aux mallocs ordinaires. C'est à dire. si vous le réglez sur 0, le fork sera copié lors de l'écriture. Copier en écriture signifie qu'une fois l'application forkée, les deux copies partageront les pages de mémoire util enfant ou l'original commence à changer de mémoire.
Dans la plupart des distributions, je sais que le surengagement est de 0. Mais si vous le réglez sur 2, toutes les pages de mémoire seront entièrement sauvegardées par de la mémoire réelle et, dans certains cas, sous une pression de mémoire élevée, elles seront plus stables, mais certains programmes (j'ai fait face à gitk) qui s'appuient sur les overcommits échouera.