Changes between Version 15 and Version 16 of AS6-TME-B6


Ignore:
Timestamp:
Mar 28, 2022, 7:17:28 AM (3 years ago)
Author:
franck
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AS6-TME-B6

    v15 v16  
    88Vous pouvez lire les [htdocs:cours/Archi-2-B6-alloc-2p.pdf slides de cours] pour voir les détails, mais voici le résumé des principes en quelques lignes.
    99
    10 - kO6 propose l'API `list` permettant de gérer les listes chaînées
    11   - Cette API est définie dans le fichier `common/list.h` utilisable par le noyau et par l'application.
    12   - L'API `list` chaîne des éléments de liste de type `list_t`, structure composée d'un double pointeur pointant vers d'autres structures `list_t`.
    13   - Les éléments de liste sont embarqués dans des structures porteuses. Ce sont les éléments de liste qui sont chaînés, mais l'API `list` permets de retrouver le pointeur sur la structure porteuse.
    14   - L'API `list` permets l'ajout et l'extraction d'éléments de liste au début, au milieu ou à la fin d'une liste. Elle permet aussi l'ajout d'élément en utilisant une relation d'ordre pour obtenir des listes triées.
     10- kO6 propose une API nommée `list` permettant de gérer les listes chaînées
     11  - Cette API est définie dans le fichier `common/list.h` et elle est utilisable par le noyau et par l'application.
     12  - L'API `list` permet de chaîner des éléments de liste de type `list_t`, laquelle est une structure composée d'un double pointeur pointant vers d'autres structures `list_t`.
     13  - Les éléments de liste sont embarqués dans des structures porteuses.
     14  - Ce sont les éléments de type `list_t` qui sont chaînés entre eux, mais l'API `list` permets de retrouver le pointeur sur la structure porteuse de l'élément.
     15  - L'API `list` permets l'ajout et l'extraction d'éléments de liste au début, au milieu ou à la fin d'une liste.
     16  - L'API `list` permets aussi l'ajout d'élément en utilisant une relation d'ordre choisie par l'utilisateur pour obtenir des listes triées.
    1517  - L'API `list` permets le parcours de tous les éléments d'une liste.
    1618
    1719- Le code user de l'application (on dira juste application dans la suite) et le noyau ont besoin d'allouer dynamiquement de la mémoire.
    18   - L'application et le noyau disposent chacun d'un segment d'adresse propre, nommé respectivement `.data` et `.kdata`, pour leurs données. Ces segments ont été partiellement remplis par des variables globales du programme au moment de son chargement en mémoire.
     20  - L'application et le noyau disposent chacun d'un segment d'adresse propre, nommé respectivement `.data` et `.kdata`, pour leurs données.
     21  - Ces segments ont été partiellement remplis par les variables globales du programme au moment de leur chargement en mémoire.
    1922  - Les allocateurs dynamiques utilisent l'espace libre de ces segments `data`.
    2023  - L'application a 2 besoins distincts d'allocation dynamiques :
    21     1. l'allocation de variables dynamiques,
    22     1. l'allocation de piles pour les threads.
     24    1. l'allocation de variables dynamiques avec une API utilisateur `malloc`/`free`
     25    1. l'allocation de piles pour les threads avec une API ad hoc utilisée par le noyau.
    2326  - Les différences entre ces deux types de types d'allocation sont les suivantes :
    2427    - D'un côté, les variables dynamiques sont allouées par l'application en fonction de ses besoins. La taille des variables est quelconque, allant de quelques octets à plusieurs mégaoctets (tant que c'est possible dans la mémoire disponible).
    25     - D'un autre côté, les piles des threads sont certes dans l'espace utilisateur, mais elles sont allouées par le noyau au moment de la création des threads. Leur taille est standard et fixe (dans un vrai système, on peut choisir leur taille, mais pas pour kO6).
     28    - D'un autre côté, les piles des threads sont certes dans l'espace utilisateur, mais elles sont allouées par le noyau au moment de la création des threads. Leur taille est standard et fixe (dans un vrai système, on peut choisir leur taille à la création du thread, mais pas pour kO6).
    2629
    2730- Nous avons donc 3 allocateurs dans kO6 :
    28   - un allocateur de piles utilisateurs pour les threads
    29   - un allocateur de variables dynamiques pour l'application
    30   - un allocateur de variables dynamiques pour le noyau
    31   - L'allocateur de piles utilisateur et l'allocateur de variables doivent partager la zone libre laissée dans la section `.data`. L'allocateur de pile utilise la partie haute de la section `.data` et l'allocateur de variable utilise la partie basse.
     31  - un allocateur de variables dynamiques pour l'application ;
     32  - un allocateur de piles utilisateurs pour les threads de l'application mais utilisé par le noyau ;
     33  - un allocateur de variables dynamiques pour le noyau.
     34  - L'allocateur de piles utilisateur et l'allocateur de variables doivent partager la zone libre laissée dans la section `.data`. Ainsi l'allocateur de piles utilise la partie haute de la section `.data` et l'allocateur de variables utilise la partie basse.
    3235
    3336- L'allocateur de piles pour les threads
    34   - C'est le plus simple. Il alloue les piles en réservant un segment de taille fixe (`USTACK_SIZE` défini dans `common/usermem.h`) à partir du haut du segment data, tant que cela n'entre pas en collision avec l'allocateur de variables dynamiques.
     37  - C'est l'allocateur le plus simple. Il alloue les piles en réservant un segment de taille fixe (`USTACK_SIZE` défini dans `common/usermem.h`) à partir du haut du segment `.data`, tant que cela n'entre pas en collision avec l'allocateur de variables dynamiques qui utilise le bas de ce même segment.
    3538  - Lors de la libération, la pile est mise dans une liste chaînée triée par adresses décroissantes en utilisant l'API `list`.
    3639  - Lors de l'allocation, la liste de piles libres est consultée en premier, avant de créer une nouvelle pile.
    3740  - Le tri des piles libres permet d'augmenter la probabilité d'usage des piles placées en haut du segment `.data`.
    38   - Quand une pile est libérée et qu'elle est la plus basse en adresse. Le segment qu'elle occupait est rendu au noyau.
     41  - Quand une pile est libérée et qu'elle est celle placée à l'adresse la plus basse, alors la place qu'elle occupait est rendue au noyau.
    3942
    4043- L'allocateur de variables dynamiques pour l'application