ordonnancement

README.md

@@ -24,8 +24,12 @@ Rappels sur la gestion de la [mémoire](cours/memoire.pdf), [td1](td/td1/td1.pdf
 #### Semaine 2 (07/09 - 11/09)
 [Système de fichiers et api E/S](cours/fichier.pdf), [td2](td/td2/td2.pdf), [tp2](tp/tp2). 
 
-#### Semaine 3 (15/09 - 19/09)
+#### Semaine 3 (14/09 - 18/09)
 [Processus](cours/processus.pdf), [interruption/ordonnancement](cours/interruption_ordoanncement.pdf), [td3](td/td3/td3.pdf), [tp3](tp/tp3).
 
+#### Semaine 4 (21/09 - 25/09)
+[interruption/ordonnancement](cours/interruption_ordoanncement.pdf), [td4](td/td4/td4.pdf), [tp4](tp/tp4).
+
+
 
 

tp/tp4/README.md

@@ -0,0 +1,6 @@
+# Interruptions - Ordonnancement
+
+- partie 1 : [interruptions](interruptions.md)
+- partie 2 : [Ordonnamcement](ordonnancement.md)
+
+

tp/tp4/cpu.c

@@ -0,0 +1,13 @@
+#include <stdio.h>
+
+
+int main(int argc, char *argv[])
+{
+	    unsigned long long i = 0;
+
+    while (1)
+        i++;
+
+
+	return 0;
+}

tp/tp4/illegal.c

@@ -0,0 +1,16 @@
+#include <stdio.h>
+
+void (fonction) (void)
+{
+	asm volatile (".byte 255, 255, 255, 255");
+//	asm volatile ("ud2");
+}
+
+int main(int argc, char * argv[])
+{
+	fprintf(stderr, "J'execute la fonction avec le code invalide...\n");
+	fonction();
+	fprintf(stderr, "Et me voici de retour\n");
+	return 0;
+}
+

tp/tp4/interruptions.md

@@ -0,0 +1,206 @@
+# Interruptions - Ordonnancement
+
+- partie 1 : [interruptions](interruptions.md)
+- partie 2 : [Ordonnamcement](ordonnancement.md)
+
+#### Ex1 :  
+Linux fournit les compteurs d'interruptions dans :
+
+```bash
+cat /proc/interrupts
+```
+
+Exécutez :
+
+```bash
+cat /proc/interrupts
+```
+
+Vous devriez obtenir un tableau comportant notamment une colonne par CPU.
+
+Pour connaître le nombre de processeurs logiques :
+
+```bash
+nproc
+```
+
+Vous pouvez également utiliser :
+
+```bash
+lscpu
+```
+
+1. Combien de processeurs logiques possède votre machine ?
+2. Combien de colonnes correspondant aux CPU observez-vous dans `/proc/interrupts` ?
+3. À quoi correspond chaque ligne du tableau ?
+4. Pourquoi les compteurs sont-ils différents selon les CPU ?
+
+#### Ex2 
+Une interruption matérielle peut être générée lorsqu'un périphérique demande l'attention du processeur.
+Sur un PC traditionnel, le clavier est associé à l'IRQ 1.
+Recherchez les informations relatives au clavier :
+
+```bash
+grep -i keyboard /proc/interrupts
+```
+
+Vous pouvez également rechercher le contrôleur `i8042` :
+
+```bash
+grep i8042 /proc/interrupts
+```
+
+Sur de nombreuses machines, vous observerez une ligne semblable à :
+
+```text
+1:    ...    IR-IO-APIC   1-edge   i8042
+```
+
+Le numéro `1` est le numéro d'IRQ.
+
+Le suffixe :
+
+```text
+1-edge
+```
+
+indique que cette interruption est configurée en mode déclenché sur front (*edge-triggered*).
+
+
+Dans un terminal, lancez :
+
+```bash
+watch -n 1 'grep "^ *1:" /proc/interrupts'
+```
+
+Puis appuyez plusieurs fois sur des touches.
+
+1. Le compteur de l'IRQ 1 augmente-t-il lorsque vous utilisez le clavier ?
+2. Sur quel CPU le compteur augmente-t-il ?
+3. Pourquoi le clavier n'a-t-il pas besoin d'être interrogé en permanence par le processeur ?
+4. Quelle différence faites-vous entre :
+   - une interruption ;
+   - une interrogation périodique (*polling*) ?
+
+#### Ex3
+
+Linux permet de contrôler les processeurs auxquels une IRQ peut être distribuée.
+
+Pour l'IRQ 1 :
+
+```bash
+cat /proc/irq/1/smp_affinity
+```
+
+Vous pouvez également utiliser :
+
+```bash
+cat /proc/irq/1/effective_affinity
+```
+
+et :
+
+```bash
+cat /proc/irq/1/effective_affinity_list
+```
+
+1. Quel est le masque d'affinité pour l'IRQ 1 sur votre machine ?
+2. Quel(s) CPU(s) est(sont) séléctionné(s) pour la gérer ?
+3. Y-a-t-il un interêt à la gérer toujours sur le même cpu ?
+
+#### Ex4
+Sur une machine multicœur, un processeur peut avoir besoin de demander une action à un autre processeur.
+
+Linux utilise alors des **IPI** (*Inter-Processor Interrupts*).
+
+Examinez :
+
+```bash
+cat /proc/interrupts
+```
+
+Recherchez notamment les lignes :
+
+```text
+LOC
+RES
+CAL
+TLB
+```
+
+Les significations importantes sont :
+
+- `LOC` : interruptions du timer local ;
+- `RES` : demandes de réordonnancement ;
+- `CAL` : appels de fonctions entre CPU ;
+- `TLB` : invalidations de TLB entre CPU.
+
+
+#####  `LOC` : timer local
+
+`LOC` correspond aux interruptions du timer local de chaque CPU.
+
+Elles permettent notamment au noyau d'effectuer certaines opérations liées :
+
+- à la gestion du temps ;
+- à la comptabilisation du temps CPU ;
+- à l'ordonnancement.
+
+
+1. Pourquoi chaque CPU possède-t-il son propre compteur `LOC` ?
+
+
+##### `RES` : rescheduling
+
+Une ligne `RES` correspond à des demandes de réordonnancement transmises entre CPU.
+
+Par exemple, un CPU peut devoir signaler à un autre CPU qu'il doit réévaluer le processus actuellement exécuté.
+
+
+1. Pourquoi un CPU peut-il avoir besoin de demander à un autre CPU de réévaluer son ordonnancement ?
+
+
+##### `TLB` — TLB shootdown
+
+Le TLB (*Translation Lookaside Buffer*) contient des traductions récentes :
+
+```text
+adresse virtuelle → adresse physique
+```
+
+Supposons qu'un CPU modifie les tables de pages d'un processus.
+
+Un autre CPU peut encore posséder dans son TLB une ancienne traduction.
+
+Linux doit alors demander à ce CPU d'invalider l'entrée correspondante.
+
+Il peut utiliser une IPI.
+
+Le mécanisme est souvent appelé :
+
+> **TLB shootdown**
+
+
+1. Pourquoi une modification des tables de pages peut-elle nécessiter une action sur un autre CPU ?
+2. Pourquoi le TLB doit-il être invalidé ?
+3. Une IPI TLB provient-elle d'un périphérique matériel externe ?
+
+#### Ex4 
+
+Pour déclencher  l’exception `Illegal instruction`  , il faut exécuter  du code
+invalide  pour le  processeur employé.  C’est difficile  avec les  architectures
+actuelles  car les  pages  de  code sont  verrouillées  en  lecture seule  (donc
+impossible de modifier des fonctions existantes) et les pages de données ne sont
+pas exécutables (donc impossible d’y dérouter l’exécution).
+
+La  solution consiste  à  générer un  code assembleur  invalide  et à  l’insérer
+manuellement  dans  un  programme  C,  comme   c’est  fait  dans  le  fichier  
+illegal.c  (les  instructions sont invalides pour un  processeur x86, il
+faudra peut-être changer les valeurs si on le teste sur une autre architecture).
+
+1. Observez l'effet avec 
+   ```bash
+   strace ./illegal
+   ```
+   Comment l'exception s'est traduite au niveau du processus fautif ?
+

tp/tp4/ordonnancement.md

@@ -0,0 +1,399 @@
+# Interruptions - Ordonnancement
+
+- partie 1 : [interruptions](interruptions.md)
+- partie 2 : [Ordonnamcement](ordonnancement.md)
+
+
+#### Ex1 1
+
+Ouvrez un terminal et exécutez :
+
+```bash
+ps
+```
+
+Puis :
+
+```bash
+ps -f
+```
+
+et :
+
+```bash
+ps -eo pid,ppid,stat,ni,pri,psr,comm
+```
+
+Cette dernière commande affiche notamment :
+
+- `PID` : identifiant du processus ;
+- `PPID` : identifiant du processus père ;
+- `STAT` : état du processus ;
+- `NI` : valeur de nice ;
+- `PRI` : priorité affichée par Linux ;
+- `PSR` : numéro du processeur sur lequel le processus s'est exécuté ;
+- `COMMAND` : nom du programme.
+
+### Questions
+
+1. Quelle est la valeur de `nice` d'un processus nouvellement créé ?
+2. Quelles valeurs peut prendre `nice` ?
+3. Que signifie une valeur de `nice` élevée ?
+4. Que signifie l'état `R` ?
+5. Que signifie l'état `S` ?
+6. Pourquoi le champ `PSR` peut-il changer au cours du temps ?
+
+
+#### Ex2.
+
+Nous allons créer un programme très simple qui consomme du temps processeur.
+
+Créez le fichier `cpu.c` :
+
+```c
+#include <stdio.h>
+
+int main(void)
+{
+    unsigned long long i = 0;
+
+    while (1)
+        i++;
+
+    return 0;
+}
+```
+
+Compilez-le :
+
+```bash
+gcc -O2 -o cpu cpu.c
+```
+
+Lancez-le :
+
+```bash
+./cpu
+```
+
+Dans un autre terminal :
+
+```bash
+top
+```
+
+### Questions
+7. Quel pourcentage de CPU utilise le processus `cpu` ?
+8. Observez le champ `NI`.
+9. Observez le champ `PR`.
+10. Sur quel processeur le processus s'exécute-t-il ? 
+
+Utilisez :
+
+```bash
+watch -n 0.1 ps -C cpu -o pid,ni,pri,psr,comm
+```
+
+11. Appuyez sur `1` dans `top`. Que constatez-vous concernant les différents processeurs ?
+
+Pour arrêter le programme :
+
+```bash
+killall cpu
+```
+
+#### Ex3 
+
+Lancez maintenant **deux** instances :
+
+```bash
+./cpu &
+./cpu &
+```
+
+Puis :
+
+```bash
+watch -n 0.1 ps -C cpu -o pid,ni,pri,psr,pcpu,comm
+```
+
+et observez avec :
+
+```bash
+top
+```
+
+### Questions
+
+12. Si votre machine possède plusieurs processeurs logiques, les deux processus utilisent-ils nécessairement le même processeur ?
+13. Lancez quatre processus :
+
+```bash
+./cpu &
+./cpu &
+./cpu &
+./cpu &
+```
+
+Observez leur utilisation CPU.
+
+14. Que se passe-t-il si vous lancez davantage de processus que votre machine ne possède de processeurs logiques ?
+15. Pourquoi un processus CPU-bound finit-il malgré tout par laisser le processeur à un autre processus ?
+
+
+#### Ex4
+
+La commande `nice` permet de lancer un processus avec une valeur de `nice` particulière.
+
+Lancez :
+
+```bash
+nice -n 10 ./cpu &
+```
+
+Puis :
+
+```bash
+watch -n 0.1 ps -C cpu -o pid,ni,pri,pcpu,comm 
+```
+
+Comparez avec un processus lancé normalement :
+
+```bash
+./cpu &
+```
+
+### Questions
+
+16. Quelle est la valeur de `nice` des deux processus ?
+17. Leur valeur de `PRI` est-elle identique ?
+18. Que signifie concrètement `nice = 10` ?
+19. Est-ce que `nice` signifie que le processus est exécuté « moins souvent » au sens strict ?
+
+
+#### Ex5 
+
+Lancez deux processus :
+
+```bash
+./cpu &
+./cpu &
+```
+
+Repérez leurs PID :
+
+```bash
+pgrep cpu
+```
+
+Choisissez l'un des deux PID et modifiez sa valeur de nice :
+
+```bash
+renice 10 -p PID
+```
+
+par exemple :
+
+```bash
+renice 10 -p 12345
+```
+
+Observez :
+
+```bash
+ps -p 12345 -o pid,ni,pri,pcpu,comm
+```
+
+### Expérience
+
+Essayez de faire tourner simultanément deux processus `cpu` :
+
+- l'un avec `nice = 0` ;
+- l'autre avec `nice = 10`.
+
+Observez leur consommation CPU pendant plusieurs secondes.
+
+### Questions
+
+20. Le processus avec `nice = 10` reçoit-il toujours du CPU ?
+21. Que constatez-vous lorsque les deux processus se disputent le même processeur ?
+22. Si les deux processus peuvent s'exécuter simultanément sur deux processeurs différents, l'effet de `nice` est-il aussi visible ?
+23. Expliquez pourquoi.
+
+> **Attention :** `nice` modifie la priorité relative d'un processus, mais ne lui réserve pas une quantité fixe du processeur.
+
+
+#### Ex6
+
+Linux permet de restreindre les processeurs sur lesquels un processus peut s'exécuter.
+
+Utilisez :
+
+```bash
+nproc
+```
+
+pour connaître le nombre de processeurs logiques disponibles.
+
+Lancez :
+
+```bash
+taskset -c 0 ./cpu &
+```
+
+Puis :
+
+```bash
+ps -C cpu -o pid,psr,pcpu,comm 
+```
+
+Vous pouvez également consulter directement l'affinité :
+
+```bash
+taskset -p PID
+```
+
+### Questions
+
+24. Sur quel processeur le processus est-il autorisé à s'exécuter ?
+25. Pourquoi le champ `PSR` reste-t-il normalement égal à `0` ?
+26. Quelle différence faites-vous entre :
+
+```text
+nice
+```
+
+et :
+
+```text
+taskset
+```
+
+
+#### Ex7
+
+Nous allons maintenant forcer deux processus à utiliser **le même processeur**.
+
+Lancez :
+
+```bash
+taskset -c 0 ./cpu &
+taskset -c 0 ./cpu &
+```
+
+Observez :
+
+```bash
+top
+```
+
+Puis :
+
+```bash
+ps -C cpu -o pid,ni,pri,psr,pcpu,comm 
+```
+
+### Questions
+
+27. Les deux processus peuvent-ils s'exécuter simultanément sur le CPU 0 ?
+28. Quelle proportion approximative du temps processeur reçoit chaque processus ?
+
+Modifiez maintenant la priorité du premier processus :
+
+```bash
+renice 10 -p PID1
+```
+
+et laissez le second avec :
+
+```text
+nice = 0
+```
+
+29. Observez à nouveau `top`.
+30. Expliquez qualitativement l'effet de `nice` lorsque deux processus CPU-bound sont contraints de partager le même processeur.
+
+#### Ex8 
+
+Linux fournit de nombreuses informations sur chaque processus dans :
+
+```text
+/proc/PID/
+```
+
+Pour un processus `cpu`, examinez :
+
+```bash
+cat /proc/PID/status
+```
+
+puis :
+
+```bash
+cat /proc/PID/sched
+```
+
+Dans `sched`, recherchez notamment :
+
+```text
+se.sum_exec_runtime
+nr_switches
+nr_voluntary_switches
+nr_involuntary_switches
+```
+
+### Questions
+
+31. Que représente `se.sum_exec_runtime` ?
+32. Quelle différence faites-vous entre :
+
+- changement de contexte volontaire ;
+- changement de contexte involontaire ?
+
+33. Pourquoi un processus `cpu` devrait-il avoir relativement peu de changements de contexte volontaires ?
+
+
+#### Ex9 
+
+Nous allons mettre en place l'expérience suivante :
+
+- deux processus `cpu` ;
+- tous deux limités au CPU 0 ;
+- processus A : `nice = 0` ;
+- processus B : `nice = 15`.
+
+Lancez-les :
+
+```bash
+taskset -c 0 ./cpu &
+```
+
+et :
+
+```bash
+taskset -c 0 nice -n 15 ./cpu &
+```
+
+Notez leurs PID.
+
+Après environ 30 secondes, récupérez :
+
+```bash
+cat /proc/PID_A/sched
+cat /proc/PID_B/sched
+```
+
+Relevez notamment :
+
+```text
+se.sum_exec_runtime
+nr_switches
+```
+
+### Questions
+
+34. Le temps CPU obtenu par A et B est-il identique ?
+35. Comparez les valeurs de `se.sum_exec_runtime`.
+36. Quelle conclusion pouvez-vous tirer sur l'influence de `nice` ?
+37. Pourquoi cette expérience est-elle plus significative lorsque les deux processus sont attachés au **même CPU** ?
+