1) oui bien sûr sans overcommit mmap ou malloc va retourner une erreur (enfin dans la majorité des cas). L'intérêt de split-stack sans overcommit c'est que tu pourras créer plus de threads, et gâcher moins de mémoire. Je suis d'accord que le comportement n'est pas déterministe, mais je ne pense pas que les cas ciblés soient le temps-réel ou les systèmes embarqués.
Il y a plein de cas où l'overcommitting est désactivé : par exemple tu évoques les problèmes de déterminisme, or l'OOM est hautement imprévisible. Sinon, il est souvent conseillé de le désactiver avec certaines bases de données, http://www.network-theory.co.uk/docs/postgresql/vol3/LinuxMemoryOvercommit.html.
Enfin, il y a plein de systèmes qui ne supportent pas l'overcommitting (gcc ne compile pas que du code destiné à tourner sous Linux avec un MMU).
2) tout à fait d'accord, mais la probabilité d'occurrence de débordement de pile est plus faible
3) je me suis posé la même question. Il faudra que je vérifie le code, mais j'ai bien l'impression que c'est le nombre de pages mappées qui est pris en compte dans la politique de pagination. A creuse.
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.
Tu as l'air d'avoir une approche systèmes embarqués temps-réel, mais je ne suis pas sûr que splitstacks s'adresse à ce type de cas.
[^] # Re: ...
Posté par neologix . En réponse à la dépêche La version 4.6 du compilateur GCC est disponible. Évalué à 2.
1) oui bien sûr sans overcommit mmap ou malloc va retourner une erreur (enfin dans la majorité des cas). L'intérêt de split-stack sans overcommit c'est que tu pourras créer plus de threads, et gâcher moins de mémoire. Je suis d'accord que le comportement n'est pas déterministe, mais je ne pense pas que les cas ciblés soient le temps-réel ou les systèmes embarqués.
Il y a plein de cas où l'overcommitting est désactivé : par exemple tu évoques les problèmes de déterminisme, or l'OOM est hautement imprévisible. Sinon, il est souvent conseillé de le désactiver avec certaines bases de données, http://www.network-theory.co.uk/docs/postgresql/vol3/LinuxMemoryOvercommit.html. Enfin, il y a plein de systèmes qui ne supportent pas l'overcommitting (gcc ne compile pas que du code destiné à tourner sous Linux avec un MMU).
2) tout à fait d'accord, mais la probabilité d'occurrence de débordement de pile est plus faible
3) je me suis posé la même question. Il faudra que je vérifie le code, mais j'ai bien l'impression que c'est le nombre de pages mappées qui est pris en compte dans la politique de pagination. A creuse.
Tu as l'air d'avoir une approche systèmes embarqués temps-réel, mais je ne suis pas sûr que splitstacks s'adresse à ce type de cas.