Heu, c'est moi ou un modèle 1:1 est justement plus adapté à des machines massivement multi processeurs qu'un modèle M:N puisqu'il permet plus de parallélisme.
Le pire de tout c'est le 1:N , dans ce cas là grosso-modo c'est quasiment comme si les threads n'existait pas. Tout se dérouel en userland et totu est rattaché au même processus (donc au même thread kernel, donc au même CPU)
Le 1:1 permet pas mal de parallelisation, mais il a ses limites. L'immense avantage de la gestion 1-on-1 est qu'elle ne nécessite pas du tout de planificateur en userland, il suffit généralement de rajouter quelques signaux au planificateur de processus pour s'en sortir.
Le M:N est très complexe à mettre en oeuvre, il nécessite deux scheduler (un en kernelland et un en userland) et il faut en plus que ces deux planificateur soient très bien coordonés. Cependant, il est celui qui offre le plus de flexibilité : dans un modèle avec un SA (Scheduler Activation) le kernel distribue des processeurs virtuels à tous les processus qui font appels aux threads et peut mettre à jour le nombre de processeurs virtuels attribués dynamiquement. Ca permet de constament adapter les threads à la charge effective des processus. Sous certaines conditions on peut même déplacer un thread d'un processeur à l'autre. Mais bon c'ets clair que vu l'overhead impliqué au niveau système, il vaut mieux avoir du processeur disponible, sinon ca sert pas à grand chose.
[^] # Re: ...
Posté par Jerome Herman . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 5.
Le pire de tout c'est le 1:N , dans ce cas là grosso-modo c'est quasiment comme si les threads n'existait pas. Tout se dérouel en userland et totu est rattaché au même processus (donc au même thread kernel, donc au même CPU)
Le 1:1 permet pas mal de parallelisation, mais il a ses limites. L'immense avantage de la gestion 1-on-1 est qu'elle ne nécessite pas du tout de planificateur en userland, il suffit généralement de rajouter quelques signaux au planificateur de processus pour s'en sortir.
Le M:N est très complexe à mettre en oeuvre, il nécessite deux scheduler (un en kernelland et un en userland) et il faut en plus que ces deux planificateur soient très bien coordonés. Cependant, il est celui qui offre le plus de flexibilité : dans un modèle avec un SA (Scheduler Activation) le kernel distribue des processeurs virtuels à tous les processus qui font appels aux threads et peut mettre à jour le nombre de processeurs virtuels attribués dynamiquement. Ca permet de constament adapter les threads à la charge effective des processus. Sous certaines conditions on peut même déplacer un thread d'un processeur à l'autre. Mais bon c'ets clair que vu l'overhead impliqué au niveau système, il vaut mieux avoir du processeur disponible, sinon ca sert pas à grand chose.
Pour plus de détails : http://people.redhat.com/drepper/Scheduler.pdf