Qu'on fasse le switch en user-space ou par le noyeau ce qu'il y a à faire est à peu près la même chose non ?
Oui, à peu près.
je concois mal que le noyeau aille alors moins vite que du code en user space. Il doit surement y avoir des choses faites en trop puisque vous semblez d'accord, lesquelles ?
Comme l'a dit pBpG plus haut, le noyau tourne aussi vite que le reste, ce qui est coûteux c'est le guichet pour passer de mode user à mode noyau.
En gros : pour passer dans le noyau tu laches une interruption, le handler sauvegarde tout le contexte, recharge celui du noyau, fait sa sauce, appelle l'ordonnanceur pour savoir sur qui retomber en sortie, recharge le processus décidé comme suivant et sort du noyau.
Dans le cas de threads au sein d'un même processus, il y a sauvegarde du contexte, chargement du suivant, point.
Ce qui est encore plus couteux quand on est en mode noyau c'est la création de processus : il faut choper une entrée de processus libre, mmap-er tous les segments de mémoire qui vont bien, le mettre dans la file du scheduler, etc. Pour le détruire, pareil, il faut libérer toutes ses ressources, etc. Sans compter que chaque passage dans le noyau est un passage dans l'ordonnanceur global et que le processus perd donc la main. Dans le cas du mode utilisateur tu à juste à créer un nouveau contexte local et te lancer dessus.
Dans le cas d'applis qui utilisent massivement les threads au sens création/destruction les threads user peuvent être plus intéressants que les processus.
[Je suppose que l'on parle bien de threads en mode utilisateur]
Sinon, pour ton exemple, mon exemple de départ n'était qu'un exemple (eh oui). Le comportement de l'ordonnanceur n'est pas défini dans la spec. Techniquement le passage au processus multithreadé donne la main à l'ordonnanceur local du processus qui gère ses threads comme il veut.
Pour reprendre ton schéma c'est (par exemple) :
A th1 (chgt ctx user) A th2 (chgt ctx KRNL) B (chgt ctx KRNL) A th2 (cght ctx user) A th1 ...
Au niveau du noyau, les processus sont en multi-tâche préemptif. Au niveau des threads (en mode user) c'est du multi-tâche coopératif. Le plus souvent les threads ne consomment pas tout le quantum de temps du processus, bien au contraire.
Une fois encore, il faut choisir son type de threads en fonction de l'appli. Plus un thread va être long et consommer des ressources et plus une solution orientée vers les processus va être intéressante. Plus une appli sera massivement multi-threadé avec beaucoup de threads à la vie courte et plus la solution « user-space » sera intéressante.
[^] # Les threads, ces êtres incompris :)
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 5.
Oui, à peu près.
Comme l'a dit pBpG plus haut, le noyau tourne aussi vite que le reste, ce qui est coûteux c'est le guichet pour passer de mode user à mode noyau.
En gros : pour passer dans le noyau tu laches une interruption, le handler sauvegarde tout le contexte, recharge celui du noyau, fait sa sauce, appelle l'ordonnanceur pour savoir sur qui retomber en sortie, recharge le processus décidé comme suivant et sort du noyau.
Dans le cas de threads au sein d'un même processus, il y a sauvegarde du contexte, chargement du suivant, point.
Ce qui est encore plus couteux quand on est en mode noyau c'est la création de processus : il faut choper une entrée de processus libre, mmap-er tous les segments de mémoire qui vont bien, le mettre dans la file du scheduler, etc. Pour le détruire, pareil, il faut libérer toutes ses ressources, etc. Sans compter que chaque passage dans le noyau est un passage dans l'ordonnanceur global et que le processus perd donc la main. Dans le cas du mode utilisateur tu à juste à créer un nouveau contexte local et te lancer dessus.
Dans le cas d'applis qui utilisent massivement les threads au sens création/destruction les threads user peuvent être plus intéressants que les processus.
[Je suppose que l'on parle bien de threads en mode utilisateur]
Sinon, pour ton exemple, mon exemple de départ n'était qu'un exemple (eh oui). Le comportement de l'ordonnanceur n'est pas défini dans la spec. Techniquement le passage au processus multithreadé donne la main à l'ordonnanceur local du processus qui gère ses threads comme il veut.
Pour reprendre ton schéma c'est (par exemple) :
A th1 (chgt ctx user) A th2 (chgt ctx KRNL) B (chgt ctx KRNL) A th2 (cght ctx user) A th1 ...
Au niveau du noyau, les processus sont en multi-tâche préemptif. Au niveau des threads (en mode user) c'est du multi-tâche coopératif. Le plus souvent les threads ne consomment pas tout le quantum de temps du processus, bien au contraire.
Une fois encore, il faut choisir son type de threads en fonction de l'appli. Plus un thread va être long et consommer des ressources et plus une solution orientée vers les processus va être intéressante. Plus une appli sera massivement multi-threadé avec beaucoup de threads à la vie courte et plus la solution « user-space » sera intéressante.