Sur mon poste de travail par exemple, je pense que dans 99,9% des cas, le scheduleur, faute de concurrent, réaffecte le même processus au processeur.
Oui, mais non. Pour éviter la famine, plus un processus utilise le CPU et moins il peut l'utiliser (bon, si les autres n'en veulent pas ils ne le prennent pas mais ils passent quand même un peu de temps sur le CPU). En utilisation station de travail, il se passe toujours quelque chose : X11 en attente sur les évenements extérieurs à souvent la main, et les processus qui recoivent les évenements X11 aussi.
Ça fait au moins 2 processus : le serveur X et une xterm (par exemple, ça marche aussi avec getty et un shell). Et l'action de l'un fait réagir l'autre.
De toutes façons, par la construction même du scheduler, il y a quasiment toujours un concurrent (à moins qu'il n'y ai qu'un seul processus au total qui [puisse] tourner).
Je n'arrive pas trop à voir de cas « vrai monde réel » où un processus est schédulé deux fois de suite après avoir consommé tout son quantum de temps. Si on regarde en [1] et [2], les seuls cas possibles sont « un seul processus » et « tous les processus ont épuisé leur crédit temps ». Et même dans ce dernier cas, la structure de donnée (file) passe le plus ancien d'abord.
> Pour la TLB, au pire elle s'invalide toute seule.
Je ne comprends pas cette remarque. Elle est déclarée invalide lorsqu'on modifie le registre qui pointe sur la page des tables, ce n'est pas 'tout seul'.
Certes. En fait j'étais dans un autre délire (c'est le défaut de vouloir appliquer ce que l'on fait en ce moment à l'univers en général).
Au context-switch de processus il est nécessaire d'invalider la TLB (puisque chaque processus à son espace virtuel à lui). J'ai répondu trop vite et j'étais encore sur les threads en mode « user », donc je pensais que tu voulais invalider la TLB au thread switch pour que chaque thread aie son cache bien propre. Je fatigue parfois :)
[^] # Re: Un seul processus actif ?
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 2.
Oui, mais non. Pour éviter la famine, plus un processus utilise le CPU et moins il peut l'utiliser (bon, si les autres n'en veulent pas ils ne le prennent pas mais ils passent quand même un peu de temps sur le CPU). En utilisation station de travail, il se passe toujours quelque chose : X11 en attente sur les évenements extérieurs à souvent la main, et les processus qui recoivent les évenements X11 aussi.
Ça fait au moins 2 processus : le serveur X et une xterm (par exemple, ça marche aussi avec getty et un shell). Et l'action de l'un fait réagir l'autre.
Le cas « un seul processus à besoin de tourner » est très improbable. L'optimisation est dans le noyau linux mais est marquée « unlikely », cf .http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L624(...)">http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L624(...(...))">http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L624(...(...(...)))
De toutes façons, par la construction même du scheduler, il y a quasiment toujours un concurrent (à moins qu'il n'y ai qu'un seul processus au total qui [puisse] tourner).
Je n'arrive pas trop à voir de cas « vrai monde réel » où un processus est schédulé deux fois de suite après avoir consommé tout son quantum de temps. Si on regarde en [1] et [2], les seuls cas possibles sont « un seul processus » et « tous les processus ont épuisé leur crédit temps ». Et même dans ce dernier cas, la structure de donnée (file) passe le plus ancien d'abord.
Certes. En fait j'étais dans un autre délire (c'est le défaut de vouloir appliquer ce que l'on fait en ce moment à l'univers en général).
Au context-switch de processus il est nécessaire d'invalider la TLB (puisque chaque processus à son espace virtuel à lui). J'ai répondu trop vite et j'étais encore sur les threads en mode « user », donc je pensais que tu voulais invalider la TLB au thread switch pour que chaque thread aie son cache bien propre. Je fatigue parfois :)
[1] http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L161(...)">http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L161(...(...))">http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L161(...(...(...)))
[2] http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L596(...)">http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L596(...(...))">http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L596(...(...(...)))