Changes between Version 54 and Version 55 of AS6-TME-B6

Timestamp:

Mar 30, 2022, 9:35:56 AM (3 years ago)

Author:

franck

Comment:

--

AS6-TME-B6

@@ -265 +265 @@
 Les exercices sont classés par niveau de difficultés supposées (on est jamais à l'abri de surprise)
 
-En préalable de tous les exercices, quelques questions sur le code. Dans le répertoire `s6` vous trouvez le répertoires `01_malloc` qui contient le code complet des allocateurs et la modification du code de kentry pour le changement de pile.
+En préalable de tous les exercices, quelques questions sur le code. Dans le répertoire `s6` vous trouvez le répertoire `01_malloc` qui contient le code complet des allocateurs et la modification du code de kentry pour le changement de pile.
 {{{
 01_malloc
@@ -313 +313 @@
 
 Dans le code ci-après, on peut voir la fonction `try_malloc()` appelée par la fonction `malloc()`.
-On voit que les blocs sont parcouru depuis `Heap.beg` le premier bloc jusqu'au dernier `Heap.end` (qui n'est pas vraiment un bloc mais une frontière). Lisez le code et trouvez comment recommencer le prochain `try_malloc()` à partir de dernier bloc alloué. Ce n'est pas difficile, mais il faut comprendre...
+On voit que les blocs sont parcourus depuis `Heap.beg` le premier bloc jusqu'au dernier `Heap.end` (qui n'est pas vraiment un bloc, mais une frontière). Lisez le code et trouvez comment recommencer le prochain `try_malloc()` à partir de dernier bloc alloué. Ce n'est pas difficile, mais il faut comprendre...
 
 **ulib/memory.c**
@@ -368 +368 @@
     block_info_t *ptr = try_malloc (size);                  // Search for a block
     if (ptr == NULL) {                                      // if no free space
-        merge (Heap.beg);                                   // merge all free blocks from beginning
+        merge (Heap.beg);                                   // merge all free blocks from the beginning.
         ptr = try_malloc (size);                            // try again to find a block
     }
@@ -379 +379 @@
 
 
-Plus difficile, passer l'allocateur en best-fit. Je ne vous demande pas d'écrire le code, sauf si vous avez le temps et la motivation. En revanche, vous pouvez réfléchir à la manière de procéder. Pour vous aidez, l'idée, c'est de ne pas toucher aux chaînages des blocs utilisés par first-fit. Il faut créer un chaînage ordonné par taille des blocs libres en utilisant l'API `list` et l'utiliser pour trouver le bloc de la bonne taille. Ce n'est très difficile mais il y a pleins de détails à régler, par exemple, décider de ce que l'on lors d'un ''merge'' des blocs libres.
+Plus difficile, passer l'allocateur en best-fit. Je ne vous demande pas d'écrire le code, sauf si vous avez le temps et la motivation. En revanche, vous pouvez réfléchir à la manière de procéder. Pour vous aider, l'idée, c'est de ne pas toucher aux chaînages des blocs utilisés par first-fit. Il faut créer un chaînage ordonné par taille des blocs libres en utilisant l'API `list` et l'utiliser pour trouver le bloc de la bonne taille. Ce n'est très difficile, mais il y a pleins de détails à régler, par exemple, décider de ce qu’on lors d'un ''merge'' des blocs libres.
 
 
@@ -387 +387 @@
 Vous savez peut-être que dans un processeur disposant d'un mécanisme permettant à chaque application d'avoir son propre espace d'adressage (espace d'adressage virtuel), les accès à la mémoire passe par un composant de traduction d'adresses nommé **MMU** pour traduire les adresses virtuelles de l'application en adresses physiques de l'espace d'adressage physique où se trouvent les segments de mémoire physique (gérés par les bancs de mémoire). 
 
-L'un des rôles de ce composant **MMU** (Memory Management Unit) est de tester la légalité des accès à la mémoire. Si le noyau attribut un segment d'adresses à une application. Si l'application tente d'accéder en dehors de ce segment, la MMU le détecte et prévient le noyau par une exception. C'est l'erreur fatale ''Segmentation Fault'' que vous avez certainement déjà eu.
-
-Le SoC **almo1** n'a pas de MMU, donc pas de gestion de mémoire virtuelle, or nous voulons tester que les segments d'adresses définis pour les deux piles de threads ne débordent pas. Pour ce faire, les deux piles de threads (user et kernel) ont des nombres magiques (`MAGIC_STACK`) dans leur premier et dernier mot. Ces mots ne devraient jamais être écrasés, si cela se produit, c'est que les piles ont été corrompues ou qu'elles ont débordé. 
+L'un des rôles de ce composant **MMU** (Memory Management Unit) est de tester la légalité des accès à la mémoire. Si le noyau attribue un segment d'adresses à une application. Si l'application tente d'accéder en dehors de ce segment, la MMU le détecte et prévient le noyau par une exception. C'est l'erreur fatale ''Segmentation Fault'' que vous avez certainement déjà eue.
+
+Le SoC **almo1** n'a pas de MMU, donc pas de gestion de mémoire virtuelle, toutefois nous voulons tester que les segments d'adresses définis pour les deux piles de threads ne débordent pas. Pour ce faire, les deux piles de threads (user et kernel) ont des nombres magiques (`MAGIC_STACK`) dans leur premier et dernier mot. Ces mots ne devraient jamais être écrasés, si cela se produit, c'est que les piles ont été corrompues ou qu'elles ont débordé. 
 
 L'idée est de tester à intervalle régulier que les nombres magiques sont toujours présents, par exemple lors des changements de threads. C'est un bon moment parce qu'on peut tester que les piles du thread sortant n'ont pas débordé pendant son exécution et que les piles du thread entrant sont correctes avant de lui donner un cœur. 
@@ -429 +429 @@
 Dans le fichier `kernel/kmemory.c`, on peut voir qu'il existe un tableau `Objects[]` contenant autant de cases qu'il existe de taille d'objets possibles (mesurée en nombre de lignes) et dont chaque case contient le nombre d'objets alloués de cette taille. Ce tableau a 256 cases au maximum (si la ligne de cache fait 16 octets), la case 0 contient le nombre de pages allouées, la case 1 contient le nombre d'objets alloués d'1 ligne, la case 2 pour les objets de 2 lignes, etc.
 
-Il n'y a pas de tableau pour compter le nombre d'objets libres dans les listes d'objets. L'idée c'est d'en ajouter un, et ne pas demander la suppression de slab si le nombre d'objet est inférieur à un seuil choisi (qui pourrait être 1).
+Il n'y a pas de tableau pour compter le nombre d'objets libres dans les listes d'objets. L'idée c'est d'en ajouter un, et ne pas demander la suppression de slab si le nombre d'objets est inférieur à un seuil choisi (qui pourrait être 1).
 
 **kernel/kfree**