Que fait un process CPU inactif?

Je sais que cela semble absurde, quelque chose de "ralenti" devrait restr inactif et ne rien faire, mais s'il vous plaît supportez avec moi.

En regardant la source de strace j'ai trouvé l'utilisation du drapeau clone CLONE_IDLETASK qui est décrit là comme:

 #define CLONE_IDLETASK 0x00001000 /* kernel-only flag */ 

Après avoir regardé plus en profondeur, j'ai constaté que, bien que ce drapeau ne soit pas couvert par man clone il est effectivement utilisé par le kernel pendant le process de démarrage pour créer des process inactifs (qui doivent tous avoir un PID 0) pour chaque CPU de la machine. c'est-à-dire qu'une machine avec 8 CPU aura au less 7 (voir la question ci-dessous) de tels process "en cours d'exécution" (guillemets).

Maintenant, cela m'amène à quelques questions sur ce que fait ce process "inactif". Mon hypothèse est qu'elle exécute le fonctionnement NOP de manière continue jusqu'à ce que son time se termine et que le kernel affecte un process réel pour exécuter ou affecter le process inactif une fois de plus (si le CPU n'est pas utilisé). Pourtant, c'est une supposition complète. Alors:

  1. Sur une machine avec, disons, 8 processeurs, 7 process inactifs seront créés? (et un CPU sera tenu par le kernel lui-même alors qu'aucun espace user performant ne fonctionne?)

  2. Le process d'inactivité est-il vraiment un stream infini d'opérations NOP? (ou une boucle qui fait la même chose).

  3. L'utilisation du processeur (par exemple, uptime ) est-elle simplement calculée par combien de time le process d'inactivité était-il sur le CPU et combien de time il n'était pas là pendant une certaine période de time?


PS Il est probable qu'une bonne partie de cette question est due au fait que je ne comprends pas très bien comment fonctionne un CPU. c'est-à-dire que je comprends l'assemblage, les timeouts et les interruptions mais je ne sais pas comment, par exemple, une CPU peut utiliser plus ou less d'énergie en fonction de son exécution. Je serais reconnaissant si quelqu'un peut m'éclairer là aussi.

La tâche d'inactivité est utilisée pour la comptabilité des process et également pour réduire la consommation d'énergie. Sous Linux, une tâche inactive est créée pour chaque processeur et verrouillée sur ce processeur; chaque fois qu'il n'y a pas d'autre process à exécuter sur cette CPU, la tâche d'inactivité est planifiée. Le time passé dans les tâches inactives apparaît comme du time "inactif" dans des outils tels que le top . (La disponibilité est calculée différemment.)

Unix semble avoir toujours eu une boucle inactive (mais pas nécessairement une tâche d'inactivité, voir la réponse de Gilles ), et même dans V1, il a utilisé une instruction WAIT qui arrêtait le processeur jusqu'à ce qu'une interruption se produise pour l'interruption "). Certains autres systèmes d'exploitation utilisaient les loops chargées, DOS, OS / 2 et les premières versions de Windows en particulier. Depuis un certain time déjà, les processeurs utilisent ce type d'instruction "wait" pour réduire leur consommation d'énergie et leur production de chaleur. Vous pouvez voir différentes implémentations de tâches inactives dans arch/x86/kernel/process.c dans le kernel Linux: la base appelle simplement HLT , ce qui arrête le processeur jusqu'à ce qu'une interruption se produise (et active le mode d'économie d'énergie C1) , les autres implémentations gèrent divers bugs ou inefficacités ( par exemple en utilisant MWAIT au lieu de HLT sur certaines CPU).

Tout cela est complètement séparé des états inactifs dans les process, lorsqu'ils attendent un événement (E / S, etc.).

Dans la design du manuel d'un ordonnanceur de process, si le planificateur n'a aucun process à planifier (c'est-à-dire si tous les process sont bloqués, en attente d'input), le planificateur attend une interruption du processeur. L'interruption peut indiquer l'input d'un périphérique (action de l'user, package réseau, lecture terminée à partir d'un disque, etc.) ou une interruption du temporisateur qui triggers un temporisateur dans un process.

Le planificateur de Linux n'a pas de code spécial pour un cas à faire. Au lieu de cela, il encode le cas des choses à faire comme un process spécial, le process d'inactivité. Le process d'inactivité n'est planifié que si aucun autre process n'est programmable (il a effectivement une priorité infiniment faible). Le process d'inactivité fait en fait partie du kernel: il s'agit d'un thread kernel, c'est-à-dire d'un thread qui exécute du code dans le kernel, plutôt que de coder dans un process. (Plus précisément, il existe un tel thread pour chaque CPU.) Lorsque le process d'inactivité s'exécute, il exécute l'opération d'attente d'interruption.

La durée d'attente d'interruption dépend des capacités du processeur. Avec la design de processeur la plus basique, c'est juste une boucle occupée –

 nothing: goto nothing 

Le processeur continue à exécuter une instruction de twig pour toujours, ce qui ne fait rien. La plupart des systèmes d'exploitation modernes ne le font pas à less qu'ils ne fonctionnent sur un processeur où il n'y a rien de mieux, et la plupart des processeurs ont quelque chose de mieux. Plutôt que de dépenser de l'énergie à ne rien faire sauf chauffer la pièce, idéalement, le processeur devrait être éteint. Le kernel exécute donc du code qui ordonne au processeur de s'éteindre ou au less d'éteindre la plupart du processeur. Il doit y avoir au less une petite partie qui rest sous tension, le controller d'interruption. Lorsqu'un périphérique triggers une interruption, le controller d'interruption envoie un signal de réveil à la partie principale du processeur.

En pratique, les processeurs modernes tels que Intel / AMD et ARM disposent de nombreux parameters de gestion de l'alimentation complexes. Le operating system peut estimer combien de time le processeur restra en mode veille et choisira différents modes de faible puissance en fonction de cela. Les modes offrent différents compromis entre la consommation d'énergie au repos et le time nécessaire pour entrer et sortir du mode veille. Sur certains processeurs, le operating system peut également réduire la fréquence d'horloge du processeur lorsqu'il constate que les process ne consumnt pas beaucoup de time CPU.

Non, une tâche inactive ne gaspille pas les cycles du processeur. Le planificateur ne sélectionne simplement pas un process inactif pour l'exécution. Un process inactif attend qu'un événement se produise afin qu'il puisse continuer. Par exemple, il peut attendre une input dans un appel système read() .

Par ailleurs, le kernel n'est pas un process distinct. Le code du kernel est toujours exécuté dans le context d'un process (à l'exception du cas particulier d'un thread du kernel), donc il n'est pas correct de dire «et un CPU sera tenu par le kernel alors qu'aucun espace user ne fonctionne».