Comme dit dans mon précédent post il existe 4 priorités de processus, et donc une file par priorité. Une file représente un nombre n de processus de priorité x en Ready State. 
#sh processes
PID     QTy PC          Runtime (ms) Invoked uSecs      Stacks          TTY     Process
22      Mwe 628250A4    0               1       0       2516/3000       0       RMI RM Notify Wa
23      Hwe 60092C38    0               2       0       5508/6000       0       SMART
24      Msp 612FAFB0    76              170778  0       5540/6000       0       GraphIt
25      Mwe 613B193C    0               2       0       11504/12000     0       Dialer event
26      Mwe 624E81B0    0               1       0       5540/6000       0       SERIAL A'detect
27      Mwe 62AC6984    0               2       0       11516/12000     0       XML Proxy Client
28      M*      0       456             153298  0       9356/12000      194     SSH Process
29      Mwe 602AFC70    0               1       0       2484/3000       0       Inode Table Dest
30      Cwe 62818F90    0               1       0       5548/6000       0       Critical Bkgnd
31      Mwe 6033D7D8    96              102962  0       10208/12000     0       Net Background
32      Mwe 6033DA68    0               2       0       11420/12000     0       IDB Work
33      Lwe 6128EEEC    2184            9209    237     10088/12000     0       Logger
Dans ce « show processes » on peut voir les 4 priorités de processus ainsi que le processus en Running State. Dans la colonne Q :
  • L : Low Priority (background process non utile au fonctionnement du routeur)
  • M : Medium Priority (priorité par défaut)
  • H : High Priority (processus agissant par exemple sur les paquets reçus)
  • C : Critical Priority (allocation de ressources, processus cœur du système)
  • K : Killed
  • D : Crashed
  • X : Corrupted
Dans la colonne Ty :
  • * : Processus en Running State
  • S : Processus qui a fait appel à un Suspend
  • E : Processus qui attend un évènement
  • rd : Processus en Ready State
  • we : Processus en Idle State qui attend un évènement
  • sa : Processus en Idle State qui attend une certaine heure
  • si : Processus en Idle State qui attend la fin d’un intervalle
  • sp : Processus en Idle State qui attend la fin d’un intervalle périodique
  • st : Processus en Idle State qui attend l’expiration d’un timer
  • hg : Processus bloqué
  • xx : Processus Dead
Les autres colonnes :
  • PID : Process ID …
  • PC : pointeur vers le code du processus, là où le CPU s’était arrêté la fois passée (0 = running)
  • Runtime : temps total que le processus à occupé sur le CPU
  • Invoked : nombre de fois que le processus est passé en Running State
  • uSec : temps moyen sur le CPU à chaque passage
  • Stacks : utilisation du stack par le processus /taille totale du stack pour ce processus
  • TTY : ce processus est-il relié à un STDIN/STDOUT, si oui, la valeur est différente de 0 et pointe vers le TTY/VTY spécifié (#show line pour le visualiser).
#show line
Tty     Line    Typ Tx/Rx       A Modem Roty AccO AccI  Uses    Noise Overruns    Int
0       0       CTY             -     -          -       -      -       0       0       0/0     -
1       1       AUX 9600/9600   -     -          -       -      -       0       0       0/0     -
*194    194     VTY             -     -          -       -      -       3       0       0/0     -
195     195     VTY             -     -          -       -      -       0       0       0/0     -
196     196     VTY             -     -          -       -      -       0       0       0/0     -
  • Process : nom du processus
Revenons au scheduler : image 1. Le scheduler démarre avec le Critical Priority Stack et exécute tous les processus s’y trouvant. 2. S’il n’y a plus rien dans Critical, le scheduler passe au High Priority Stack et exécute le premier processus. Une fois le premier processus exécuté, le scheduler vérifie la présence de processus dans la Critical Stack. S’il y en a, le scheduler les exécute. Le scheduler peut donc passer au processus suivant du High Priority Stack. Le scheduler vérifie après chaque processus High Priority Stack la présence de processus de plus haut niveau pour les exécuter. 3. S’il n’y a plus de processus Critical, ni de processus High, le scheduler passe au Medium Priority Stack. Entre chaque processus du Medium Priority Stack, le scheduler vérifie la présence de processus dans le High Priority Stack. S’il y en a, il exécute le premier puis vérifie la présence de processus dans le Critical Priority Stack et les exécute tous. Une fois le Critical vide, il passe au High Priority suivant, etc … 4. S’il n’y a plus de processus Critical, ni de processus High, ni de processus Medium, le scheduler passe au Low Priority Stack. (A savoir que si l’on vient du Medium Priority Stack on ne passe pas au Low Priority Stack. A la fin du Medium on passe au Critical Priority Stack, lorsque cette étape a été réalisée 15 fois on passe finalement au Low Priority Stack – Ca c’est du LOW). Entre chaque processus en Low Priority le scheduler vérifie le Medium Stack et exécute les processus du Medium Stack entre-lesquels le scheduler vérifie la présence de processus dans le High Stack et les exécute tout en vérifiant entre chaque processus High la présence de processus Critical pour les exécuter tous avant de passer au suivant High. 5. On retourne à l’étape 1. Si un processus devient fou (>4sec sur le CPU), pas de problèmes ! Le WatchDog Timer est là pour l’interrompre ! Le WatchDog Timer est exécuté via une interrupt (toutes les 4msec via le system timer), donc plus prioritaire que n’importe quel processus. La notification d’arrivée de paquet est aussi une interrupt. Ainsi l’IOS peut directement traiter le paquet. Je reviendrai prochainement sur les méthodes existantes de Switching de Paquets. Prochain post: l’organisation mémoire de l’IOS.