D'un autre côté, lors d'un fork, le processus père et le processus fils ont chacun une copie de ce qui était la mémoire du père avant le fork.
Dans les faits, c'est mis en oeuvre par du copy-on-write : les deux processus partagent les mêmes pages de mémoire qui sont marqué en lecture seule. Lors d'un accès en écriture, le noyau est prévenu, il effectue la copie, marque la page copié comme accessible en écriture et rend la main.
Pour revenir à nos moutons (ou plutôt à nos processus dans le cas présent) lors d'un fork, le processus fils a tendance à effectuer un exec juste après le fork, c'est à dire qu'il va charger un exécutable et donc réinitialiser son espace mémoire.
Que se passe-il alors si le père garde la main
père : je fork
noyau : ok, je te crée un fils et je te laisse la main
père : je modifie la mémoire à tel endroit
noyau : hep, hep ,hep, c'est protégé en écriture là, laisse moi copier ça à un endroit où tu emmerdera pas ton fils
père : je modifie la mémoire à tel autre endroit ...
(répéter quelques fois)
noyau : bon, ça suffit là, je te préempte et je passe la main au fils
fils : bon, balance moi toute cette mémoire qui m'est allouée et charge les données depuis /bin/pornviewer
noyau : ah bah c'était bien la peine que je copie toutes ces pages mémoire pour rien
On le voit bien, à la fin le noyal est dépité et c'est très certainement pour éviter ça que les développeurs avaient choisi de donner la main au fils en premier. Cependant aujourd'hui les évaluations de perf montrent qu'il vaut mieux ça que de payer le coût d'un changement de contexte.
C'est peut être du à l'utilisation de solutions crées pour éviter ce problème de copies de pages inutiles comme l'utilisation de vfork au lieu de fork par exemple, mais je ne suis pas expert dans le domaine.
[^] # Re: Fils ou pere?
Posté par Julien . En réponse à la dépêche Nouvelle version 2.6.32 du noyau Linux. Évalué à 9.
Dans les faits, c'est mis en oeuvre par du copy-on-write : les deux processus partagent les mêmes pages de mémoire qui sont marqué en lecture seule. Lors d'un accès en écriture, le noyau est prévenu, il effectue la copie, marque la page copié comme accessible en écriture et rend la main.
Pour revenir à nos moutons (ou plutôt à nos processus dans le cas présent) lors d'un fork, le processus fils a tendance à effectuer un exec juste après le fork, c'est à dire qu'il va charger un exécutable et donc réinitialiser son espace mémoire.
Que se passe-il alors si le père garde la main
père : je fork
noyau : ok, je te crée un fils et je te laisse la main
père : je modifie la mémoire à tel endroit
noyau : hep, hep ,hep, c'est protégé en écriture là, laisse moi copier ça à un endroit où tu emmerdera pas ton fils
père : je modifie la mémoire à tel autre endroit ...
(répéter quelques fois)
noyau : bon, ça suffit là, je te préempte et je passe la main au fils
fils : bon, balance moi toute cette mémoire qui m'est allouée et charge les données depuis /bin/pornviewer
noyau : ah bah c'était bien la peine que je copie toutes ces pages mémoire pour rien
On le voit bien, à la fin le noyal est dépité et c'est très certainement pour éviter ça que les développeurs avaient choisi de donner la main au fils en premier. Cependant aujourd'hui les évaluations de perf montrent qu'il vaut mieux ça que de payer le coût d'un changement de contexte.
C'est peut être du à l'utilisation de solutions crées pour éviter ce problème de copies de pages inutiles comme l'utilisation de vfork au lieu de fork par exemple, mais je ne suis pas expert dans le domaine.