1) dans quel cas la non utilisation de l'overcommit et split-stack serait utile ?
Un des usages de ne pas utiliser l'overcommit, c'est de ne pas avoir de OOM killer (non l'OOM killer ne se déclenche pas a la création des threads, mais on a une belle erreur du pthread_create suite au mmap de la stack qui échoue) mais un comportement ou l'on peut catcher les erreurs.
Dans ce cas l'utilisation des split-stack est débile : on introduit un comportement non prédictible (si la taille de la stack doit etre augmenté et qu'il n'y a plus de memoire, que fait on ?).
De plus la non utilisation de l'overcommit est pas évidente. Tu connais des exemples de système qui l'utilise ?
2)
dans le cas classique on a la stack plus une page de garde pour catcher les débordement de pile. Avec ce système il faudra rajouter du code qui gère tout les cas de débordement de pile (allocation statique par le compilo, tableau sur la pile de taille variable, alloca, ...).
3)
J'ai pas tout suivi. Si tu alloue des pages, mais que tu n'utilises pas encore, ca influence les algo de swapping de linux ?
Pourquoi ne pas améliorer ces algos dans ce cas. Les stacks ne sont pas le seul cas de ce cas d'usage.
En plus l'utilisation en contexte embarqué des split-stack est peu recommandable pour les tâches RT. Dans le cas classique on peut pre-faulter la stack, ici on aura des mmap automatique en cours de vie du programme.
[^] # Re: ...
Posté par M . En réponse à la dépêche La version 4.6 du compilateur GCC est disponible. Évalué à 3.
1) dans quel cas la non utilisation de l'overcommit et split-stack serait utile ?
Un des usages de ne pas utiliser l'overcommit, c'est de ne pas avoir de OOM killer (non l'OOM killer ne se déclenche pas a la création des threads, mais on a une belle erreur du pthread_create suite au mmap de la stack qui échoue) mais un comportement ou l'on peut catcher les erreurs.
Dans ce cas l'utilisation des split-stack est débile : on introduit un comportement non prédictible (si la taille de la stack doit etre augmenté et qu'il n'y a plus de memoire, que fait on ?).
De plus la non utilisation de l'overcommit est pas évidente. Tu connais des exemples de système qui l'utilise ?
2)
dans le cas classique on a la stack plus une page de garde pour catcher les débordement de pile. Avec ce système il faudra rajouter du code qui gère tout les cas de débordement de pile (allocation statique par le compilo, tableau sur la pile de taille variable, alloca, ...).
3)
J'ai pas tout suivi. Si tu alloue des pages, mais que tu n'utilises pas encore, ca influence les algo de swapping de linux ?
Pourquoi ne pas améliorer ces algos dans ce cas. Les stacks ne sont pas le seul cas de ce cas d'usage.
En plus l'utilisation en contexte embarqué des split-stack est peu recommandable pour les tâches RT. Dans le cas classique on peut pre-faulter la stack, ici on aura des mmap automatique en cours de vie du programme.