# Simulation de la charge d'un système conversationnel avec application aux interpréteurs partagés

Alexandre Brandwajn

<figure><img src="image_1.png" /></figure>

## To cite this version:

Alexandre Brandwajn. Simulation de la charge d'un système conversationnel avec application aux interpréteurs partagés. [Rapport de recherche] IRIA-RR-109, IRIA. 1975, pp.10. hal-04716113

HAL Id: hal-04716113

https://inria.hal.science/hal-04716113v1

Submitted on 1 Oct 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
RIA
laboria

laboratoire de recherche
en informatique
et automatique

Simulation de la charge
d'un système conversationnel
avec application
aux interprèteurs partagés

A. Brandwajn

<figure><img src="image_3.png" /></figure>

Institut de Recherche
d'Informatique
et d'Automatique

Domaine de Voluceau
Rocquencourt
78150 - Le Chesnay
Tél. 954.90.20

Rapport de Recherche n° 109.

Mars 1975
# SIMULATION DE LA CHARGE D'UN SYSTEME CONVERSATIONNEL AVEC APPLICATION AUX INTERPRÉTEURS PARTAGÉS

A. Brandwajn

## Résumé

Nous décrivons un simulateur d'usagers interactifs réalisé pour le système ESOPE ; nous mettons en évidence les principes qui ont préside à cette réalisation et nous insistons sur les problèmes d'interface avec le système, de prise de measure et de perturbations introduites par le simulateur. Nous montrons aussi un exemple d'application possible du simulateur à la conception de systèmes à partage de ressources en évaluant l'amélioration que l'on peut attendre de l'implantation de traducteurs partagés.

## Abstract

We describe a simulator of interactive users designed for the ESOPE system ; we point out the design principles and the problems of interface with the operating system, of measurements and of perturbations caused by the simulator. We also show an example of a possible application of the simulator to the design of multiaccess systems by evaluating the improvement one may expect from implementing shared translators.
# 1 - Introduction

Cet article est consacré à quelques aspects de la simulation de la charge d'un système à accès multiples.

Nous avons eu la grande chance de pouvoir disposer d'un système à partage de ressources n'étant pas en exploitation normale ce qui nous a permis de le modifier à notre guise sans avoir à nous préoccuper de problèmes de fiabilité du système après modification. Il s'agit du système ESOPE conçu et réalisé à l'Institut de Recherche d'Informatique et d'Automatique à Rocquencourt. Plusieurs travaux décrivent le système ESOPE [Be1],[Ka1],[Kr1],[Be2] ; nous donnerons donc uniquement les précisions indispensables au fur et à mesure qu'elles deviendront nécessaires.

Nous décrivons d'abord le simulateur d'usagers interactifs réalisé pour le système ESOPE.

Nous essaierons de mettre en évidence les principes qui ont présidé à cette réalisation et nous insisterons sur les problèmes d'interface avec le système, de prise de mesure et de perturbations introduites par le simulateur.

Nous montrerons ensuite un exemple d'application possible du simulateur à la conception de systèmes en évaluant expérimentalement l'amélioration que l'on peut attendre de l'implantation de traducteurs partagés.

Le dernier paragraphe sera consacré à des remarques et conclusions concernant la conception et l'implantation de ce genre d'outils.

# 2 - Simulation de la charge du système ESOPE

## 2.1 - Introduction

Ce paragraphe décrit un simulateur de la charge du système ESOPE.

Le but est de fournir un outil programmé permettant d'étudier l'influence de diverses caractéristiques de la charge (demande de ressources) sur le comportement du système, et d'évaluer l'efficacité des différentes stratégies d'allocation des ressources en fonction de ces caractéristiques. Il est par conséquent nécessaire de disposer d'une charge présentant les propriétés suivantes :

- elle doit être _reproductible_ pour permettre une expérimentation à charge constante en vue d'une comparaison des algorithmes de gestion de ressources.

- elle doit être _connue_ et _facilement modifiable_ c'est-à-dire _paramétrée_ pour permettre une variation étalonnée de la demande de ressources.

Le système ESOPE utilise une 10070 CII, pourvue d'une mémoire paginée alimentée page par page à partir de disques. La charge du système est uniquement constituée d'utilisateurs travaillant en mode conversationnel à partir de terminaux. Pour le système, chacun d'eux est un 'usager' possédant sa mémoire virtuelle propre. Les interpréteurs sont réentrants, ce qui permet le partage des pages de code entre usagers.
Un usager passe par divers "états", en fonction des ressources qui lui sont allouées ou retirées (figure 2.1) ; les usagers dans le même état sont réunis dans une file d'attente.

<figure><img src="image_4.png" /><figcaption>Figure 2.1 : Diagramme de transition entre
états d'un usager.</figcaption></figure>

L'usager est dit _oisif_ lorsqu'il frappe sa demande ou reçoit la réponse. Après envoi d'un retour-chariot, signifiant la fin du message, l'usager oisif devient _prêt_ c'est-à-dire candidat pour l'entrée en mémoire. Un usager admis en mémoire est dit _courant_ ; la condition d'admission est que la mémoire allouable doit pouvoir contenir tous les "working sets" estimés des usagers courants. Les usagers courants sont initialement _éligibles_, c'est-à-dire prêts à recevoir l'unité centrale ; l'usager _élu_ perd l'unité centrale :

- lorsque l'exécution d'une commande est terminée (retour à l'état oisif),

- en fin de quantum ou de temps de résidence (retour à l'état éligible ou prêt),

- lors d'un défaut de page (transition dans l'état suspendu, jusqu'à ce que la page soit chargée ou bien transition dans l'état _prêt_ si dépassement du "working set" estimé).

Le cycle d'une interaction comprend un _temps de réflexion_ (durée de l'état oisif) suivi d'un _temps de réponse_ (durée des états prêt et courant).

Les pages de mémoire sont allouées dynamiquement ; on distingue, parmi les pages allouables, les pages libres dont le contenu peut être écrasé, une copie existant sur disque, et les pages quasi-libres, dont le contenu a été modifié depuis le chargement et doit être sauvé avant réutilisation de la page. L'allocation alloue les pages libres avant les pages quasi-libres. Les pages libres et quasi-libres sont chaînées dans deux files d'attente.

Les demandes émises par le simulateur se limitent à deux ressources qui sont l'unité centrale et la mémoire virtuelle.

La charge est paramétrée dans le cadre d'un modèle de comportement fixé ; tout changement de ce modèle exige un changement de programme et donc une recompilation du simulateur.

## 2.2 - Modèle de comportement d'un usager

Pour simuler des usagers interactifs dans un système conversationnel, il est
nécessaire de caractériser à la fois le comportement de l'usager au terminal et les programmes soumis au système.

Chaque usager est décrit par un modèle à deux niveaux qui correspondent à ces deux aspects de son activité.

### Comportement d'un usager conversationnel

De façon macroscopique on considère que l'activité d'un usager simulé est une suite de "temps de réflexion" et des "temps de réponse". (Voir figure 2.2).

<figure><img src="image_5.png" /><figcaption>Figure 2.2</figcaption></figure>

Le premier correspond à l'intervalle de temps qui sépare la dernière sortie des résultats sur la console de l'usager et le retour chariot (RC) qui termine une nouvelle demande d'action adressée au système. Le second représente le temps qui s'écoule entre le moment où l'utilisateur finit de taper sa demande et le moment où il dispose du résultat (réponse du système) sur sa console.

Comme on le verra dans la suite, il n'y a pas d'interaction réelle avec les terminaux dans le simulateur ; cette restriction se justifie puisqu'on constate que le traitement des interruptions liées aux échanges avec les terminaux constitue un facteur négligeable dans la charge du système (voyez [Be2]).

### Comportement des programmes

Au niveau microscopique on modélise les programmes par un certain nombre de séquences de "temps de calcul" à l'intérieur d'une page suivi de référence à une adresse contenue dans une autre page de la mémoire virtuelle (voir figure 2.3).

<figure><img src="image_6.png" /><figcaption>Figure 2.3</figcaption></figure>

Seule la demande des ressources Unité Centrale et mémoire virtuelle est prise en compte ; l'activité liée aux entrées/sorties classiques n'est pas modélisée.
## 2.3 - Principes du simulateur

### Programme d'un usager simulé

L'idée de base était d'introduire le minimum de modifications dans le système et donc d'exploiter au mieux les mécanismes présents. Les usagers simulés existent et évoluent dans le système tout comme des usagers ordinaires exception faite pour l'interaction avec les terminaux. Ils exécutent tous le même programme que l'on peut résumer de la façon suivante :

#### repeat

#### begin

arrêt pendant $\Phi$ (temps de réflexion)

for i := 1 step 1 until $\Phi$ (nombre de pages virtuelles référencées)

#### begin

calcul pendant $\Phi$ (temps de calcul) ;

if $\Phi$ (code) = 1 then

référence en lecture page $\Phi$ (numéro page code)

#### else

if $\Phi$ (lecture) = 1 then

référence en lecture page $\Phi$ (numéro page données)

#### else

référence en écriture page $\Phi$ (numéro page données) ;

end ;

#### end

until fin de la simulation ;

Le symbole $\Phi$ désigne une valeur particulière d'une variable ; dans le cas de variables aléatoires il s'agit d'une réalisation (résultat d'un tirage).

Dans notre modèle, temps de réflexion, temps de calcul, nombre de pages virtuelles référencées, numéro page code, numéro page donnée sont des variables aléatoires décrites par des distributions de probabilités ; code et lecture sont des indicateurs aléatoires correspondant au fait que des probabilités sont liées au choix du segment à référencer (le programme d'usager se compose d'un segment de code et d'un segment de données), et, s'il s'agit du segment de données, au type de référence (lecture ou écriture). Il n'y a pas de difficulté de principe à utiliser des résultats de mesures réelles (trace) en entrée du simulateur.

### Interface simulateur-système

Il est possible d'avoir simultanément dans le système plusieurs classes d'usagers simulés. A l'intérieur d'une classe les usagers sont statistiquement identiques ; ils sont caractérisés par un ensemble donné de valeurs de paramètres du modèle de comportement.

L'interface du simulateur avec le système concerne essentiellement la création, l'introduction des usagers simulés et leur départ du système.
Trois nouveaux ordres ont été ajoutés au langage de commande de l'opérateur. Ils permettent respectivement :

1. La définition d'une classe d'usagers avec des paramètres de comportement spécifiés- les usagers de la classe sont créés et attendent le début de la simulation bloqués derrière un sémaphore commun.

2. Le lancement de la simulation - les usagers bloqués derrière le sémaphore commun de simulation sont libérés et commencent l'exécution du programme. On a la possibilité de spécifier la durée (en nombre d'interaction) de la simulation au bout de laquelle les usagers quittent le système.

3. L'arrêt de la simulation - la condition "fin de la simulation" prend la valeur "vrai" et les usagers quittent le système.

## Réalisation du simulateur

Le corps du simulateur de charge a été écrit en LP 10070 [Bo1], un langage à structure de bloc permettant de manier la structure fine de l'information dans la machine (éléments binaires, registres...). Ceci avait pour but de faciliter l'intégration dans le système d'exploitation, lui-même écrit en LP 10070. Malheureusement, le langage LP 10070 n'est pas adapté aux calculs en virgule flottante utiles pour la génération d'échantillons de lois de probabilité. Nous avons donc utilisé un ensemble de sous-programmes FORTRAN pour la génération des variables aléatoires. Le choix de cette solution est motivé essentiellement par deux raisons :

a) La facilité relative d'intégration de sous-programmes FORTRAN dans un langage d'assemblage,

b) La souplesse offerte grâce à la puissance de la bibliothèque FORTRAN pour d'éventuels changements de lois de probabilité.

Tous ces sous-programmes FORTRAN utilisent une procédure (sous-programme) de génération de nombres pseudo-aléatoires uniformément répartis entre 0 et 1. La méthode utilisée pour la génération de ces nombres est celle des résidus [Na1], et la procédure est écrite en LP 10070.

## Prise de mesure

Un problème important est celui des mesures (statistiques) recueillies par le système d'exploitation.

## Dispositif de mesures dans ESOPE

Les mesures sont obtenues uniquement par programmes, incorporés dans le moteur. Les statistiques portent sur les ressources (utilisation des pages, de l'utilité centrale), les usagers (files d'attente), les interpréteurs (temps de réponse, temps d'exécution des interactions) et sur diverses parties du système (fréquence d'utilisation et durée d'exécution des primitives, des programmes d'interruption).

Les intervalles de temps se calculent simplement en notant l'heure du système. La technique suivante est utilisée lorsque seule la somme des intervalles de temps
est à mémoriser : l'ordinateur possède des horloges qui déclenchent périodiquement des interruptions ; une interruption est acquittée en une seule instruction MTW qui ajoute + 1 à un compteur adressé indirectement par un pointeur ; la somme d'une suite d'intervalle se construit donc "toute seule", à la seule condition de mettre à jour le pointeur sur le compteur à chaque fois que débute un intervalle ; une même horloge peut remplir plusieurs compteurs, si l'on modifie dynamiquement la valeur du pointeur. Cette technique a été employée pour mesurer les diverses phases d'activité de l'unité centrale (pourcentage de temps en oisiveté, en attente de page, en gestion, avec un usager élu).

## Perturbations dues au simulateur.

Le simulateur, s'il est traité comme un programme ordinaire d'usager, introduit une perturbation dans les statistiques concernant l'usager simulé. Le temps d'UC est faussé essentiellement à cause des séquences de génération de variables pseudo-aléatoires ; les défauts de pages dus à la non-résidence du programme du simulateur affectent l'utilisation de la mémoire virtuelle et donc celle du disque de page et le temps de réponse du système.

Cette perturbation doit être supprimée ou au moins évaluée si l'on veut disposer d'une charge étalonnée.

Pour tenir compte de la perturbation en temps d'UC, nous avons été amenés à modifier le système de prise de mesure. La solution adoptée consiste à rendre transparentes (non imputables à l'usager) les séquences de génération : à chaque usager simulé nous avons associé deux compteurs.

Dans l'un d'entre eux on comptabilise le temps passé dans les séquences que l'on veut rendre transparentes (générations des échantillons de lois de probabilité ; l'autre fonctionne en dehors de ces séquences. La commutation de ces compteurs est faite par appel au superviseur.

<figure><img src="image_7.png" /></figure>

Le problème des défauts de page dans les séquences transparentes a été résolu par "collage" c'est-à-dire en fixant en mémoire physique pour toute la durée de la simulation les pages qui contiennent le code et les données propres (données du programme de simulation) de chacun des usagers simulés. La mémoire physique allouable est ainsi réduite d'un nombre de pages égal au nombre d'usagers simulés plus une (1 page de données privées par usager et 1 page de code commune à tous).
## 3 - Influence du partage du code dans le système ESOPE.

Une question importante que se posent souvent les concepteurs des systèmes à accès multiples est de savoir si l'on peut attendre une amélioration des performances en implantant des traducteurs (compilateurs,...) réentrants, et, dans l'affirmative, si l'amélioration ainsi obtenue justifie la complexité introduite par la gestion de fichiers partagés.

Pour apporter un élément de réponse à cette question, nous avons évalué avec le simulateur de charge l'influence du degré de partage du code dans le système ESOPE.

Voici les paramètres du simulateur maintenus fixes :

- temps moyen de réflexion : 10 s

- temps moyen de calcul à l'intérieur d'une page : 10 ms

- nombre moyen de pages virtuelles référencées par interaction : 50

- taille du segment de données : 10 pages

- taille du segment de code partagé : 50 pages

- taille du segment de code privé : 50 pages

- probabilité de référencer une page de données : 50 %

- probabilité de référencer une page de données en lecture : 50 %

- ordre de la distribution d'Erlang du temps de réflexion : 3.

Les pages à l'intérieur de chacun des segments sont référencées suivant une loi uniforme, le temps de calcul à l'intérieur d'une page virtuelle est généré selon une loi exponentielle, le temps de réflexion selon une loi d'Erlang, et le nombre de pages virtuelles distinctes référencées par interaction suit une loi binomiale. Ces distributions, de même que les valeurs des paramètres du simulateur de charge, ont été choisies de façon arbitraire.

Nous avons fait varier la probabilité qu'une référence aux segments de code concerne le code partagé. Le tableau T1 montre les résultats obtenus pour une charge de 12 et 16 usagers simulés. Nous y avons représenté dans l'ordre : les temps de réflexion et d'unité centrale des usagers par interaction; le nombre moyen de violations de protections virtuelles pour page manquante par interaction, le nombre moyen de pages vidées sur disque à chaque interaction, le nombre moyen de pages chargées du disque par interaction et la répartition du temps de l'unité centrale entre les principales activités (autres que mode usager et oisiveté totale du système). Dans la partie consacrée à l'activité de l'unité centrale nous trouvons le temps moyen passé à chaque interaction, en gestion (allocation, libération de mémoire, élection usagers, choix du degré de multiprogrammation, etc.), en attente de pages, en traitement des interruptions d'Entrées/Sorties, en analyse et traitement du déroutement '40'*, et, enfin, en préparation des requêtes au disque.

<footnote>* Une violation de protections mémoire provoque un déroutement '40' dans CII 10070.</footnote>
<table><thead><tr><th rowspan="2">Degré de partage<br>TABLEAU 1</th><th colspan="2">0%</th><th colspan="2">25%</th><th colspan="2">50%</th><th colspan="2">75%</th><th colspan="2">100%</th></tr><tr><th>(1)</th><th>(2)</th><th>(3)</th><th>(4)</th><th>(5)</th><th>(6)</th><th>(7)</th><th>(8)</th><th>(9)</th><th>(10)</th></tr></thead><tbody><tr><td>Temps de réflexion [s]</td><td>10,5</td><td>12,3</td><td>10,4</td><td>10,5</td><td>10,1</td><td>12,1</td><td>10,3</td><td>12,0</td><td>10,7</td><td>12,0</td></tr><tr><td>Temps moyen UC/interaction [ms]</td><td>420</td><td>386</td><td>427</td><td>367</td><td>407</td><td>362</td><td>386</td><td>367</td><td>377</td><td>353</td></tr><tr><td>Nombre moyen de défauts de page par interaction</td><td>37,8</td><td>49,2</td><td>41,2</td><td>44,0</td><td>39,0</td><td>45,1</td><td>35,2</td><td>40,1</td><td>29,5</td><td>35,7</td></tr><tr><td>Nombre moyen de pages vidées par interaction</td><td>1,55</td><td>4,43</td><td>3,98</td><td>6,67</td><td>3,29</td><td>5,42</td><td>2,12</td><td>4,67</td><td>1,39</td><td>3,80</td></tr><tr><td>Nombre moyen de pages chargées par interaction</td><td>23,6</td><td>34,1</td><td>23,9</td><td>29,9</td><td>16,9</td><td>22,2</td><td>9,23</td><td>13,9</td><td>2,2</td><td>6,02</td></tr><tr><td>Temps moyen de réponse [s]</td><td>3,64</td><td>8,78</td><td>4,93</td><td>9,96</td><td>3,22</td><td>6,53</td><td>1,67</td><td>3,90</td><td>0,9</td><td>1,76</td></tr><tr><td>Gestion</td><td>95</td><td>184</td><td>178</td><td>395</td><td>85</td><td>188</td><td>42</td><td>63</td><td>24</td><td>34</td></tr><tr><td>Attente de pages</td><td>383</td><td>496</td><td>420</td><td>377</td><td>345</td><td>357</td><td>225</td><td>272</td><td>105</td><td>186</td></tr><tr><td>Interruption E/S</td><td>13,1</td><td>17,4</td><td>14,0</td><td>16,6</td><td>10,7</td><td>13,3</td><td>6,5</td><td>9,3</td><td>2,1</td><td>5,5</td></tr><tr><td>Déroutement '40' analyse</td><td>10,6</td><td>13,3</td><td>11,5</td><td>11,9</td><td>10,8</td><td>12,2</td><td>9,9</td><td>11,1</td><td>8,3</td><td>9,9</td></tr><tr><td>Déroutement '40' traitement</td><td>20,0</td><td>25,7</td><td>20,5</td><td>21,8</td><td>14,8</td><td>21,3</td><td>15,9</td><td>18,1</td><td>12,6</td><td>15,1</td></tr><tr><td>Préparer requête</td><td>57,4</td><td>83,7</td><td>59,0</td><td>74,2</td><td>42,7</td><td>57,1</td><td>24,8</td><td>36,9</td><td>7,3</td><td>17,4</td></tr></tbody></table>

Nombre d'usagers simulés

12

16

12

16

12

16

12

16

12

16
<figure><img src="image_8.png" /><figcaption>Figure 3.1</figcaption></figure>
On constate que le temps moyen de réponse du système lorsque tous les usagers ne "connaissent" que le segment de code partagé est quelque **4 fois** meilleur que le temps de réponse du même système avec autant de "copies" du traducteur qu'il y a d'usagers.

La valeur élevée du temps moyen de réponse lorsque la probabilité qu'une référence aux segments de code ait lieu dans le segment partagé vaut 25 %, s'explique par le traitement des fichiers partagés dans le système ESOPE. En effet, toutes les pages référencées de ce fichier restent en mémoire principale aussi longtemps qu'il y a au moins un usager courant ayant ouvert ce fichier. Dans notre cas, ceci revient à diminuer la taille de la mémoire principale.

On remarque que, probablement à cause de cette politique de gestion des fichiers partagés, dans le système ESOPE on a intérêt à rendre les traducteurs réentrants seulement si le degré de partage du code dépasse approximativement 50 % (pour le type de charge considéré).

Ces constatations sont confirmées par l'analyse des nombres moyens de défauts de page et de pages chargées du disque par interaction, et il convient de remarquer à ce propos que, parmi les grandeurs mesurées, ce sont les nombres moyens qui sont les plus "stables", dans ce sens qu'elles subissent peu de variation si on répète la simulation. Le nombre moyen de pages vidées sur disque est un peu moins "stable", et les temps moyens de réponse et ceux passés en gestion et en attente de pages peuvent subir d'importantes fluctuations. Notons aussi que la variance (estimée) du temps de réponse est de l'ordre de la moyenne ; ceci est en partie dû à la distribution, proche de l'exponentielle, des demandes en temps d'UC générées par l'usager simulé.

Sur la figure 3.1. nous avons tracé le nombre moyen de pages chargées du disque par interaction et le temps moyen de réponse en fonction du degré de partage pour 12 et 16 usagers simulés.

Les résultats présentés dans ce paragraphe semblent militer en faveur de traducteurs partagés à condition que la probabilité de référencer le code partagé soit suffisamment élevée ; ce serait le cas, par exemple, dans un système comportant un petit nombre de traducteurs.

Une autre conclusion que l'on peut tirer de ces résultats concerne le choix de l'unité logique de partage. Dans le système ESOPE, le partage se fait au niveau du fichier, dans ce sens qu'une page appartenant à un fichier partagé, et qui a été accédée dans le passé, n'est pas libérée aussi longtemps qu'il y a en mémoire au moins un usager ayant accédé ce fichier. C'est pour cette raison que le temps moyen de réponse du système est anormalement élevé à faible degré de partage. Il serait donc préférable de choisir pour l'unité logique de partage une page ou un petit ensemble de pages.

## 4 - Remarques et conclusions

Remarquons d'abord que dans notre cas l'objectif d'avoir une charge reproductible semble pratiquement difficile à atteindre car, malgré le caractère pseudo-aléatoire des demandes générées par les usagers simulés, la charge et en général le fonctionnement du système ne sont jamais les mêmes. En effet, suivant la position du disque
de pagination telle requête plutôt que telle autre sera servie en premier, changeant ainsi l'ordre d'élection des usagers, l'état de la mémoire physique, etc.

Il existe d'autres approches au problème de la simulation de la charge d'un système d'exploitation, comme par exemple l'utilisation d'un calculateur satellite [Bo2] pour la génération de demandes de ressources ce qui diminue notablement les perturbations introduites par le simulateur.

Bien que l'approche que nous avons présentée dans cet article soit en principe relativement simple, la conception et l'implantation du simulateur de charge ont soulevé un certain de nombre de difficultés. Ces difficultés étaient dues, pour la plupart, au fait que le simulateur n'avait pas été prévu lors de la conception du système ESOPE, et que certaines actions, comme par exemple la commutation des compteurs pour réduire les perturbations, sont interdites aux usagers normaux. Certaines primitives du système ("suspendre" par laquelle un processus suspend son exécution pour une durée spécifiée, primitives de synchronisation,...) de même que la réentrance du code (tous les usagers simulés exécutent le même programme) se sont avérées très utiles, mais nous pensons que seule la conception du simulateur de charge en même temps que celle du système peut conduire à des solutions élégantes. Procéder ainsi aurait en plus l'avantage de permettre, dès l'implantation du noyau du système, un choix expérimental, à l'aide du simulateur, des politiques de gestion et des valeurs des paramètres des algorithmes du système, ce qui devrait être le rôle de ce puissant outil d'évaluation.

Notons, enfin, que le simulateur a été utilisé également pour étudier expérimentalement l'efficacité d'une politique simple d'admission des usagers à partager la mémoire physique dans un système à accès multiple [Br 1].

## REMERCIEMENTS

Je tiens à remercier Messieurs les Professeurs C. BETOURNE (Université Paul Sabatier, Toulouse) et S. KRAKOWIAK (IMAG) pour leur aide dans la conception et l'implantation du simulateur.
Références

[Be1] C. Bétourné, e.a. "Process management and resource sharing in the multiaccess system ESOPE". CACM, Décembre 1970.

[Be2] C. Bétourné et S. Krakowiak "Mesures sur un système conversationnel" Rapport Laboria 1974.

[Bo1] J. Boulenger "Ecriture de systèmes d'exploitation à l'aide d'un langage de type PL 360. Rapport Laboria n° 48, 1974.

[Bo2] L. Boi, e.a. "Osyoscope : system on auxiliary processors for measuring operating systems". in Compte rendu des journées d'études sur les recherches en mesure, simulation, modélisation des systèmes informatiques, Toulouse juin 1973.

[Br1] A. Brandwajn "Equivalence et décomposition dans les modèles à files d'attente et leur application à l'évaluation des performances de systèmes d'exploitation". Thèse d'Etat, Paris VI, Janvier 1975.

[Ka1] C. Kaiser "Conception et réalisation de systèmes à accès multiples : gestion du parallélisme". Thèse d'Etat, Paris VI, Février 1973.

[Kr1] S. Krakowiak "Conception et réalisation de systèmes à accès multiples : allocation de ressources". Thèse d'Etat, Paris VI, Février 1973.

[Na1] T. Naylor, e.a. "Computer simulation techniques", John Wiley, New York 1968.