• [^] # Re: ...

    Posté par . En réponse à la dépêche La version 4.6 du compilateur GCC est disponible. Évalué à 4.

    Linux étant lasy (COW), la stack est réellement alloué qu'a l'utilisation et chaque thread peut alloué 8MB sans consommer de la RAM physique. Du coup le seul avantage que je vois c'est pour les système qui ont un espace d’adressage limité (32 bits). Et quand je lit ce que cette option coûte (chaque fonction doit vérifier s'il faut allouer une nouvelle pile), je vois pas l’intérêt du truc.

    1) Tout le monde n'utilise pas l'overcommiting : dans ce cas, l'OOM killer va se déclencher au moment de la création des threads, et pas de leur utilisation de la stack, même s'il reste encore plein de mémoire physique disponible. Si tu utilises par exemple un pool de threads fixe, c'est une grosse limitation.
    2) Le risque de stack overflow est moindre, puisque la stack est augmentée à la demande.
    3) Même avec l'overcommiting, avoir un mémoire virtuelle importante (Committed_AS) a un impact sur les performances : le "page reclaiming code" (j'ai horreur du franglais, mais c'est plus clair) prend en compte la quantité de pages mappées pour savoir s'il doit swapper des process (swap_tendency prend en compte les valeurs mapped ratio et swappinnes). Donc rien qu'avoir un bazillion de threads qui ne font rien va augmenter la tendance du noyau à diminuer le page cache ou swapper.