Création d'un nouveau processus

Création de l'environnement de travail

Vous allez devoir recréer l'environnement de travail sur les nouvelles machines en vous référant au ​premier TP sur ALMOS-MKH. En résumé :

#copie des sources
cd /dsk/l1/misc
scp schmitt:/dsk/l1/misc/almos-mkh_tsar.tbz2 .
tar xvjf almos-mkh_tsar.tbz2

# definition des variables d'environnement
cd /dsk/l1/misc/almos-mkh_tsar
source env.sh

# compilation du noyau, des applications et generation du disque de tsar
cd /dsk/l1/misc/almos-mkh_tsar/almos-mkh
make

# compilation du prelaoder 
cd /dsk/l1/misc/almos-mkh_tsar/tsar/softs/tsar_boot/
make

# compilation du simulateur
cd /dsk/l1/misc/almos-mkh_tsar/tsar/platforms/tsar_generic_iob/
make

# execution du simulateur
./simul.x

Dans la fenêtre term1 du simuteur, lorsque le prompt du schell [ksh] apparait, vous pouvez exécuter l'application hello.elf

load /bin/user/hello.elf

Désormais le moteur de simulation est systemcass qui profite de la structuration des composants SoCLib. Un composant SoCLib sépare explicitement les fonctions de transition, de génération de Moore et de génération de Mealy dans ses automates. Sans entrer dans les détails, cela permet à systemcass de n'exécuter qu'une seule fois par cycle les fonctions de transition et de génération de Moore et limiter la simulation par relaxation aux fonctions de Mealy. Dans le cas de TSAR, cela permet un gain en vitesse de 400% environ.

En outre, systemcass permet de produire simulateur parallèle (s'exécutant en parallèle sur un ordinateur multi-core) gràce à l'API OpenMP. Le modèle SystemC de TSAR contient déjà les directives de parallélisation. Le grain de parallélisation est le cluster, c'est-à-dire qu'un thread d'OpenMP peut exécuter un nombre entier de clusters. Ainsi, on ne peut bénéficier de la parallélisation que pour les architectures de TSAR multi-clusters.

Pour demander la parallélisation, il suffit de lancer le simulateur avec le paramètre -THREADS x, où x est le nombre de threads OpenMP demandé (qui doit être au plus égal au nombre de cores, ici 6). Par exemple, pour une plateforme TSAR à 4 clusters (quel que soit le nombre de cores par cluster), après voir compilez, vous écriez :

cd /dsk/l1/misc/almos-mkh/tsar/plateforms/tsar_generic_iob/
./simul.x -THREADS 4

A titre indicatif, le simulateur de tsar_generic_iob s'exécute à environ 200KHz pour 1 cluster à 1 core sur un core du PC et à environ 100KHz pour 4 clusters à 4 cores (16 cores) en tout sur 4 cores du PC.

Questions

1. Démarrez le simulateur et exécuter l'application idbg.elf load /bin/user/idbg.elf. Cette application permet d'afficher dans la fenêtre term0 l'état de certaines structures du noyau. La commande h permet d'obtenir de l'aide.
   1. Avec la commande p, déterminer le nombre de processus sur le cluster 0.
   2. Avec la commande s, déterminer le nombre de threads alluoués au core 0 du cluster 0.

2. Modifiez dans le fichier kernel/kernel_config.h l'état des variables DEBUG_PROCESS_DESTROY, DEBUG_PROCESS_MAKE_EXEC et DEBUG_PROCESS_MAKE_FORK, recompilez ALMOS-MKH et exécutez le simulateur (il n'est pas nécessaire de le recompiler le simulateur si vous ne modifiez pas la plateforme).
   1. Les étapes du fork et de l'exec des process ksh s'affichent dans term0, commentez les messages concernant le ksh[1] (le code des fonctions fork et exec (dans le noyau) se trouve ​kernel/kern/process.h et ​kernel/kern/process.c.

3. Modifiez la plateforme pour avoir deux clusters de 1 core en changeant de 1 à 2 l'état de la variable Y_SIZE du fichier almos-mkh/params-hard.mk. Modiifiez l'état des variables DEBUG_RPC_PROCESS_MAKE_FORK et DEBUG_RPC_THREAD_KERNEL_CREATE du fichier kernel/kernel_config.h pour voir les commandes RPC. Recompilez le ALMOS-MKH, le préloader (dans tsar/softs/tsar_boot/) et le simulateur, puis exécutez avec ./simul -THREADS 2. Remaquez que puisqu'il y a deux clusters, on demande 2 threads d'OpenMP sur 2 cores du PC.