[INGI1113] : Systèmes informatiques 2 Architecture de différents systèmes d exploitation

Transcription

1 [INGI1113] : Systèmes informatiques 2 Architecture de différents systèmes d exploitation Cappart Quentin Année académique Résumé Ce document reprend un résumé du fonctionnement des différents systèmes d exploitation tels qu ils le sont expliqués dans le Stallings 1. A chaque partie, j ai noté les pages où je me suis référé comme ça si mes explications ne vous conviennent pas, vous pouvez directement aller dans le livre. Malgré toute l attention portée à la rédaction de ce document, il est possible que certaines fautes s y trouvent 2, n hésitez pas à me le signaler 3 pour que je les corrige. Par ailleurs, il manque encore toute la partie sur la gestion du file system, que je n aurai vraisemblablement pas le temps de dactylographier. 1. "Operating systems, internals and degin principles" 7eme édition pour ceux qui débarquent. 2. D aurtograf notemment. 3. quentin.cappart@student.uclouvain.be 1

2 Table des matières 1 UNIX Gestion des processus Types des processus Etats des processus Description des processus Contrôle des processus Gestion des threads Mécanismes de concurrence Pipes Messages Shared memory Semaphores Signals Gestion de la mémoire Paging system Kernel memory allocator Scheduling UNIX traditionnel UNIX SVR UNIX FreeBSD I/O Management Buffer cache Character queue Unbuffered I/O Disk scheduling Solaris Gestion des processus et des threads Architecture multithread Structure des processus Etats des threads Interruptions et threads Mécanismes de concurrence Mutual exclusion lock Reader/Writer lock Condition variables Gestion de la mémoire Scheduling I/O Management Disk scheduling Linux Gestion des processus Structure d un processus Etats des processus Contrôle des processus Gestion des threads Mécanismes de concurrence Opérations atomiques Spinlocks Barriers Gestion de la mémoire Process virtual memory Kernel memory allocation

3 3.5 Scheduling Real-time scheduling Non real time scheduling I/O Management Linux page cache Disk scheduling Elevator scheduler Deadline I/O scheduler Anticipatory I/O scheduler Windows Gestion des processus et des threads Caractéristiques des processus Multithreading Etats des threads Contrôle des processus et des threads Mécanismes de concurrence Dispatcher objects User-mode critical section Slim reader-writer locks Conditions variables Lock free operations Gestion de la mémoire Windows virtual adress map Windows paging Windows resident set management Scheduling Priorité des processus et des threads Multiprocessor scheduling I/O Management Basic I/O facilities Types d I/O Disk scheduling RAID Volume shadow copies Volume encryption Mac OS 21 3

4 1 UNIX 1.1 Gestion des processus Expliqué à partir de la page Types des processus Unix utilise deux grands types de processus, les processus systèmes et les processus utilisateurs : Les system process : Ne se lancent qu en mode kernel et exécutent le code de l OS pour faire des fonctions de maintenance, comme l allocation de mémoire et le swapping des processus. Les user process : Se lancent en user mode et exécutent des programmes utilisateurs. Il y a par ailleurs deux processus qui sont uniques. Le premier est le processus 0 qui est créé lorsque le système est lancé, c est alors le seul processus qui n est pas créé par l appel système fork(). Le deuxième est le processus 1 appelé parfois l init process qui est le fils du processus 0 et qui est l ancêtre de tous les autres processus du système. Par exemple, lorsqu un nouvel utilisateur se connecte au système, c est l init process qui va créer un processus utilisateur Etats des processus les processus dans UNIX ont beaucoup d états différents : User running. Kernel running. Ready to run, in memory. Asleep in memory. Ready to run, swapped : Il est dans la mémoire secondaire. Sleeping, swapped. Preempted : Etat lorsqu un processus passe d un kernel mode à un user mode. Le kernel peut alors préempté ce processus pour mettre un autre processus en running state. Created. Zombie : Le processus n existe plus, mais il laisse des informations sous forme de record que son parent peut récolter. Ces états étant assez clairs, je ne les détaillerais pas plus Description des processus Le process image de chaque processus contient trois grands types d informations User-level context : Contient tous les éléments essentiels du programme utilisateur. Register context : Contient toutes les informations concernant directement les registres. System-level context : Contient toutes les informations restantes que l OS a besoin pour gérer le processus. Les détails de ces trois types sont repris dans le livre Contrôle des processus Lorsqu un processus est créé par l appel système fork(), voici tout ce que l OS fait pour accueillir le nouveau processus : 1. Il alloue un slot dans la table des processus pour le nouveau processus. 2. Il assigne un ID unique au processus. 3. Il fait une copie du process image du processus parent, à l exception des mémoires partagées avec les autres processus. 4

5 4. Il incrémente un compteur pour tous les fichiers tenus par le parent, pour montrer qu un processus supplémentaire tient maintenant aussi ces fichiers. 5. Il passe le processus fils de l état ready à l état running. 6. Si tout s est bien passé, il retourne l ID du fils au processus père, et 0 au processus fils. S il y a eu un problème, c est -1 qui est renvoyé au père, et le fils n est pas créé. Tout cela est fait dans un kernel mode par le processus parent. A partir de là, le kernel peut soit rester dans le processus parent, passer à son fils, ou exécuter un tout autre processus. 1.2 Gestion des threads Page 208 Les systèmes UNIX traditionnels ne supportaient pas la programmation multithread, seulement un seul thread par processus était permis. Mais maintenant les systèmes UNIX modernes permettent une programmation multithread. 1.3 Mécanismes de concurrence Page Unix a beaucoup de moyens pour gérer la communication et la synchronisation entre les différents processus et thread, cette section va vous présenter les plus importants Pipes Les pipes sont utilisés pour des communications entre processus. Un pipe est un buffer circulaire qui permet à deux processus de communiquer sous un modèle de producteur-consommateur ; Un processus écrit, et l autre lit. Lorsqu un pipe est créé, on lui donne une taille fixée et à partir de là, on fait toutes les vérifications classiques pour voir s il y a assez de place, si le processus ne veut pas lire trop, etc Messages Les messages sont utilisés pour des communications entre processus. Un message est un bloc de byte accompagné d un type. Les appels systèmes msgsnd() et msgrcv() annoncent les processus devant envoyer et réceptionner le message Shared memory Les mémoires partagées sont utilisés pour des communications entre processus. C est le moyen de communication le plus rapide dans UNIX, un bloc de mémoire virtuelle peut être partagée par plusieurs processus Semaphores Les sémaphores sont utilisés par un processus pour déclencher certaines actions chez d autres processus. Ils ont déjà longuement été discutés dans mon autre synthèse. Leur but est d obliger aux autres processus d attendre lorsque le processus rentre dans une zone critique et qu il doit rester seul dedans Signals Les signaux sont utilisés par un processus pour déclencher certaines actions chez d autres processus. Un signal est un mécanisme software qui informe un processus qu un événement asynchrone 4 4. Un événement asynchrone est un événement qui se produit sans tenir compte de l horloge, comme une instruction illégale, la mort d un processus, etc. 5

6 s est produit. Il peut être comparé à une interruption hardware. Tous les processus ainsi que le noyau peuvent s envoyer des signaux les uns aux autres. On a généralement besoin d un "signal handler" pour chaque processus qui va dire ce que doit faire le processus quand il reçoit un signal bien précis. 1.4 Gestion de la mémoire Page Les anciennes versions de UNIX étaient prévues pour des machines indépendantes, ce qui fait que les méthodes de management de la mémoire différaient parfois assez fort d un système à l autre. Ensuite, les versions plus récentes de UNIX utilisaient simplement le principe de variable partitioning sans utiliser de mémoire virtuelle. Les implémentations courantes de UNIX utilises maintenant une mémoire virtuelle paginée, c est de ce système que nous allons parler. Ce système utilise deux schémas séparés de gestion de mémoire, le paging system et le kernel memory allocator. Cette distinction vient du fait que le paging system est beaucoup moins adapté pour gérer la mémoire dans le noyau comme nous allons le voir par la suite Paging system Ce modèle fournit une mémoire virtuelle capable d allouer des page frames situées dans la main memory aux processus. Elle est aussi capable d en allouer aux disk block buffers. Nous allons ici nous intéresser au mécanisme général de ce modèle. Ce schéma est idéal pour les processus utilisateurs ainsi que pour les disk I/O. Data structures Quatre structures de données principales sont utilisées : Page table : Il y a en général une page des tables par processus, avec une entrée pour chaque page du processus dans la mémoire virtuelle. Disk block descriptor : Chaque entrée dans cette table est associée à une page d un processus et elle décrit le copie dans le disque de la page virtuelle. Page frame data table : Décrit chaque frame de la mémoire réelle et est indexée par un frame number. Swap-use table : Il y a une swap-use table pour chaque swap device, et une entrée pour chaque page dans le device. Tous les champs de ces quatre tables sont expliqués en détail à la page 400. Page replacement C est la page frame data table qui est utilisée pour le remplacement des pages. Différents pointeurs sont utilisés pour créer des listes dans cette table. Toutes les frames disponibles sont reliées entre elles en une liste de frame dans laquelle on va amener les pages. Ce n est que lorsque le nombre de frame disponible passe en dessous d un certain seuil, qu on commence l algorithme de remplacement. Sans rentrer dans les détails, l algorithme utilisé pour le remplacement est une amélioration du clock policy algorithm qui a pour nom two-handed clock algorithm Kernel memory allocator Le principe est le suivant, le noyau génère et détruit fréquemment des petites tables et buffers au cours de l exécution, chaque fois qu on requiert une allocation dynamique de mémoire. Ces situations peuvent être les suivantes : Un appel de la routine allocb(), l allocation d une structure zombie ou d objets, etc. Une grande partie de ces blocs sont beaucoup plus petits que la taille des pages de la machine, c est pourquoi qu on n utilise pas le mécanisme de paging pour l allocation dynamique de mémoire dans le noyau. 6

7 1.5 Scheduling UNIX traditionnel Page Les UNIX traditionnels étaient uniprocesseurs et étaient conçus pour avoir un time-sharing interactive environment, c est à dire que plusieurs utilisateurs pouvaient intérargir en même temps sur le même système. L algorithme de scheduling doit alors fournir de bons temps de réponses aux différents utilisateurs et s assurer que les jobs de priorité faible ne meurent pas de faim 5. Le scheduler emploie donc un algorithme basé sur un feedback multi-level utilisant un scheduler round-robin avec des priority queues 6. Le système utilise aussi la préemption qui fait que si un processus ne s exécute pas en une seconde maximum, il est préempté. La priorité des différents processus est aussi recalculée une fois par seconde, à chaque fois qu une décision de scheduling est faite. Le but de cela est de pouvoir facilement diviser tous les processus en bandes de priorités, chaque bande regroupant un type de processus spécifiques à un domaine. D une manière générale, voici l ordre de priorité des bandes de processus : 1. Swapper 2. Block I/O device control 3. File manipulation 4. Character I/O device control 5. User processes Cet ordre fournit des résultats efficaces lors de l utilisation d I/O device UNIX SVR4 Page La révision est complète par rapport aux UNIX traditionnels. Le nouvel algorithme est conçu pour donner la plus grande priorité aux processus temps-réel, une priorité moindre aux kernel-mode process, et une priorité la plus faible aux autres user-mode process, les time-shared. Voilà les deux grosses modifications apportées par ce UNIX : L ajout de 160 niveaux de priorités répartis en trois classes principales et donc la notion de préemption qui va avec. L ajout de point de préemption. En fait, le noyau dans UNIX ne gère pas la préemption, l astuce utilisée est de spliter les étapes d exécution d un thread en différentes tranches qui doivent s exécuter sans interruption. Entre ces différentes tranches, on a donc les points de préemption qui permettent au kernel de faire des interruptions propres et de scheduler un autre processus. Généralement les "safe places" entre ces tranches sont protégées par des sémaphores. Les trois classes mentionnées plus hauts ne sont autres que les threads temps réels, les threads kernel et les time-shared. Plus concrètement, une dispatch queue est associée à chaque niveau de priorité et la scheduling se fait en round-robin. Il y a aussi une bitmap servant à montrer à l aide d un seul bit, si une queue correspondant à une priorité précisé est vide ou pas UNIX FreeBSD Page Le scheduler de ce UNIX est conçu pour rester efficace en cas de conditions difficiles (Beaucoup de demandes, grosse utilisation des ressources, etc.) et est aussi prévu pour donner de bonnes 5. Ou souffrent de starvation, au choix. 6. Voir mon autre synthèse ou le livre pour plus d explication 7

8 performances pour les plateformes multicoeurs et multiprocesseurs. Pour ces raisons, le scheduler est assez complexe et je ne présenterai ici qu un bref aperçu. Ces nouveaux schedulers avaient trois buts principaux : Gérér la processor affinity. Ce terme réfère à le scheduler à redonner à un processeur les threads qui ont souvent été exécutés sur ce dernier quand il n y a pas de processeurs au repos. Fournir un meilleur support pour les systèmes multithread et multicore. Améliorer les performances de l algorithme de scheduling, de sorte qu il ne soit pas fonction du nombre de thread dans le système. Classes de priorités au moins prioritaire : Différentes classes de priorités sont utilisées. Les voici du plus prioritaire 1. Bottom-half kernel thread : Ils sont schedulés 7 seulement par des interruptions. 2. Top-half kernel thread : Ils s exécutent jusqu à ce qu ils soient bloqués ou finis. 3. Real-time user thread : Ils peuvent s exécuter jusqu à ce qu un thread de plus haute priorité devient disponible à l exécution. 4. Time-sharing user thread : Les priorités sont souvent recalculées en fonction de différents paramètres (utilisation de ressources, etc.) 5. Idle user thread : Ils fonctionnent que quand il n y en a aucun autre prêt à fonctionner. Queue structure Attention, j ai l impression qu il y a un bug avec la figure Le scheduling se fait indépendamment pour chaque processeur. Pour chaque processeur on a trois queues qui sont maintenues. Parmi ces queues, on a deux runqueues qui implémentent les kernel, temps réel et time sharing classes, et la troisième qui est pour la classe idle. Les deux runqueues sont désignées par les label current et next. Le scheduler de chaque processeur, choisit d abord préférentiellement des threads qui sont dans la current queue, et une fois qu elle est vide, un swap avec la next queue est effectué. L utilisation de deux runqueues garanti que tous les threads de ces deux queues seront exécutés chaque fois qu il y a un switch des queues, ce qui évite la starvation. Interactivity scoring Un thread est considéré comme interactif si le ratio de son temps de repos sur son temps d exécution effectif est en dessous d un certain seuil. Des calculs savants permettent d obtenir ce seuil, ce qui permet de trier les threads qui sont interactifs des autres. Par ailleurs un thread interactif a typiquement des longs sleep time lorsqu ils attendent un input de l utilisateur. Thread migration En général il est plus désirable de scheduler des threads sur le dernier processeur qui l a exécuté 8, ce qui permet de tirer profit de la cache locale de chaque processeur. Cependant, parfois il est mieux de ne pas tenir compte de l affinité du processeur si l on veut donner du travail à un processeur au repos. C est ce qu on appelle la migration des threads, changer d un processeur lors de l exécution du thread 9. Voici deux mécanismes implémentent la migration des thread : Pull mechanism : Un processeur au repos vole un thread d un autre processeur. Cette méthode est efficace pour éviter la perte de temps de travail des processeurs mais est inefficace dans la situation où chaque processeur à du travail mais où la charge de travail est répartie de façon inégale. Cette charge se voit dans les run queues. Push mechanism : une tâche périodique évalue la situation des charges de travail actuelles et l égalise. Deux fois par seconde la tâche prend le processeur le plus chargé et celui le moins chargé et égalise leur run queues. Cette technique assure une répartition juste des threads. 7. Moi bien parler Franglais. 8. Voir la processor affinity. 9. Pas au sein même d une exécution, mais une fois qu il a été mis en attente, ou autre. 8

9 1.6 I/O Management Page Dans UNIX, chaque dispositif I/O est associé à un fichier spécial. Ces fichiers, comme tous les fichiers, sont gérés par le file system et les opérations de lecture ou d écriture se font de la même manière que des fichiers utilisateurs. Ainsi, lorsqu on veut utiliser un dispositif I/O, typiquement avec des opérations de lecture ou d écriture, les requêtes sont faites pour le fichier associé au dispositif. Plus précisément ces fichiers gèrent les autres fichiers contenus dans les dispositifs de stockage secondaire 10 et font aussi une interface entre les processus et les dispositifs, ce qui nécessaire car ces dernjiers sont traités comme des fichiers. En outre, on a deux grands types d I/O, les buffered et les unbuffered. Comme le nom le laisse supposer, les buffered I/O passent par un system buffer. Il existe deux types de buffer utilisés, les buffer cache et les character queues. Les unbuffered I/O quant à elles, utilisent plutôt le DMA qui fait en sorte que le transfert se fait directement entre le module I/O et le processus I/O dédié à la tâche Buffer cache Ce type d I/O est surtout utilisé pour les block oriented devices, comme les disques où les clefs USB. La cache est essentiellement une disk cache, les opérations I/O utilisant le disque sont donc traitées à travers la buffer cache. Le transfert de donnés entre la buffer cache et le user process space utilise toujours le DMA, cela vient du fait qu ils sont tous les deux dans la main memory et que donc le DMA est tout adapté pour ce genre de transfert. Trois listes sont utilisées pour gérer la buffer cache : Free list : Liste tous les slots 11 qui sont libres pour une allocation. Device list : Liste tous les buffers actuellement associés à un disque. Driver I/O queue : Liste les buffers qui sont en attente pour une I/O d un dispositif particulier. Tous les buffers doivent être soit dans la free list soit dans la driver I/O queue, et une fois qu un buffer a été associé à un dispositif, il le reste même s il repasse dans la free list. On peut cependant explicitement lui demander d être associé à un autre dispositif. Bien evidemment dans un soucis de performance, les listes utilisent des pointeurs sur chaque buffer plutôt que d avoir des listes séparées avec leur propre buffer. Ainsi, lorsqu une référence est faite sur un bloc de données qui se trouve dans un dispositif particulier, l OS regarde d abord si le bloc est dans la buffer cache 12. Pour le remplacement des blocs dans la cache, un algorithme last-recently-used est utilisé, et ainsi, lorsqu un buffer a été alloué pour un bloc, il ne peut plus être utilisé pour une autre allocation jusqu à ce que les autres buffers soient utilisés plus récemment Character queue Ce type d I/O est plus appropriée pour les character-oriented device, comme les imprimantes ou les terminals. La character queue peut être utilisée pour la communication entre une écriture faite parle dispositif I/O et une lecture par le processus, ou inversément. Dans ces deux cas c est un modèle producteur/consommateur qui est utilisé. Une fois qu un caractère dans la queue a été lu, il est détruit par la suite, il ne peut donc être lu qu une seule fois. Cela diffère de la buffer cache où plusieurs lectures étaient possibles Unbuffered I/O En utilisant le DMA entre le dispositif et le process space, c est la méthode la plus rapide de faire une I/O. Cependant, le processus qui effectue une unbuffered I/O est bloqué dans la main 10. Qui sont aussi des I/O device. 11. Un slot est considéré comme un buffer, chaque slot tenant un secteur du disque. 12. Pour minimiser ce temps de recherche, la liste du dispositif est organisée comme une table de hachage. 9

10 memory et ne peut plus être swappé, ce qui diminue globalement les performances du système. Par ailleurs, le dispositif I/O est avec cette technique lié au processus le temps du transfert, ce qui fait qu il est inutilisable par d autres processus. Ce type d I/O est quand même utilisé pour les I/O block oriented même si le buffer cache convient aussi. Il est aussi utilisé pour les imprimantes assez rapides (Ce qui limite ainsi les inconvénient de cette méthode), pour les plus lentes on préfère utiliser la character queue. 1.7 Disk scheduling On n en parle pas vraiment dans le livre. 2 Solaris 2.1 Gestion des processus et des threads Page Solaris implémente les threads à plusieurs niveau ce qui lui donne une bonne flexibilité dans l exploitation des processeurs Architecture multithread Solaris utilise quatre concepts différents relatifs aux threads : Process : C est le process traditionnel qui inclut une user address space, une stack et le process control block. User-level threads (ULT) : Ils sont implémentés par une libraire de thread dans l address space d un processus, ils sont invisibles pour l OS. Ils sont créés par l utilisateur. Lightweight processes (LWP) : Ces threads peuvent être vus comme un mapping entre les ULT et les kernel threads. Chaque LWP supportent un seul ULT et le map à un kernel thread. Les LWP sont schedulés par le kernel indépendamment les uns des autres et peuvent donc s exécuter en parallèle sur plusieurs processeurs. Ces threads sont visibles depuis les applications utilisateurs. Kernel threads : Les entités fondamentales qui peuvent être schedulées et dispatchées pour être lancée sur un processeur. Il y a un kernel thread pour chaque LWP à l exception de certains kernel threads spécifiques qui sont créés, exécutés et détruits très vite et qui ont pour mission d exécuter une fonction du système assez spécifique. Cette architecture de thread à trois niveaux facilite la gestion des threads par l OS et fournir une interface claire aux applications Structure des processus La structure des processus est identique à celle de UNIX à la seule différence qu à la place d avoir comme dans UNIX un processor state block, on a dans Solaris une liste de structures contenant un data block pour chaque LWP. Cette structure contient diverses informations comme l identifiant du LWP, sa priorité, un pointeur sur la process structure, etc Etats des threads Les différents états des threads reflètent l exécution des kernel threads et des LWP. Voici les différents états : RUN : Le thread est prêt à être exécuté. ONPROC : Le thread est exécuté par un processeur. SLEEP : Le thread est bloqué. STOP : Le thread est stoppé. ZOMBIE : Le thriller thread est terminé. 10

11 FREE : Les ressources du thread ont été libérées et le thread est en attente d être enlevé de l OS thread data structure Interruptions et threads Dans Solaris les interruptions sont converties en kernel threads. La motivation première de ce choix est de réduire les overheads, en effet, les interrupt handlers manipulaient trop souvent des données partagées par le reste du kernel. La solution de Solaris est la suivante : 1. Solaris emplie un groupe de kernel threads pour gérer les interruptions, ils seront appelés interrupt thread et auront leur propre identifiant, priorité, contexte et stack. 2. Le kernel controle l accès aux structures de données et synchronise certains interrupt threads en utilisant les principes d exclusion mutuelle. (Un peu flou...) 3. Les interrupt threads ont des priorités supérieures à touts les autres types de kernel threads. On peut alors gérer les interrupt threads à même titre que les autres. 2.2 Mécanismes de concurrence Page Solaris supporte les mêmes mécanismes que UNIX SVR4 en plus de quelques autres propres à lui Mutual exclusion lock Cela correspond au mutex, un seul thread à la fois peut avoir accès à une ressource protégée par un mutex Reader/Writer lock Les reader/writer lock permettent à plusieurs threads d avoir un accès simultané en lecture sur un objet protégé par un lock. Il n autorise aussi qu un seul thread à avoir accès en écriture à la ressource 13.Lorsqu un lock est tenu par un writer, tous les threads qui veulent lire ou écrire doivent attendre, s il est tenu par un ou plusieurs readers, seuls d autres readers peuvent entrer Condition variables Les conditions variables sont utilisées pour mettre des threads en attente jusqu à ce qu une condition bien particulière est à l état true. Elles sont rarement utilisées seules mais souvent avec des mutex ce qui permet d implémenter un moniteur. 2.3 Gestion de la mémoire Elle est identique à celle sur les UNIX actuels. 2.4 Scheduling Pas expliqué dans le livre, sûrement similaire à UNIX SVR4 ou BSD. 2.5 I/O Management Pas expliqué dans le livre, sûrement similaire à UNIX SVR Disk scheduling Pas expliqué dans le livre, sûrement similaire à UNIX SVR Il ne peut pas y avoir de reader evidemment. 11

12 3 Linux 3.1 Gestion des processus Page Structure d un processus Un processus, appelé aussi task dans linux, est représenté par la structure de données task s truct. Cette structure contient les informations suivantes : L état du processus. Les informations nécessaire pour pouvoir schedulé les processus. Les identifiants du processus, de l utilisateur et du groupe. Les mécanisme de communication entre processus (IPC). Les différents liens (link) des processus (Vers leur parent, leurs fils). Des informations concernant le temps ; La date de création du processus, sa durée de vie, etc. Le file system ; Cela inclut des pointeurs vers les fichiers ouverts par le processus ainsi que des pointeurs vers les dossiers relatifs au processus. L adresse virtuelle assignée au processus. Les registres et les stacks information qui constituent le contexte du processus Etats des processus Il y a cinq états principaux pour les processus : Running. Interruptible : Etat bloqué dans lequel le processus attend le déroulement d un évenement. Uninterruptible : Un autre état bloqué mais dans lequel le processus attend que des conditions au niveau hardware soient respectées. Stopped : Le processus a été arrêté est ne peut être réactivé que par l action d un autre processus. Par exemple un processus qui est en train d être debuggé peut être mis dans cet état. Zombie : Un process qui se prend pour Mickael Jackson, qui est terminé, mais qui pour des raisons particulières a encore une task s truct présente dans la table des processus Contrôle des processus Dans linux on utilise l appel systeme clone() pour créer un nouveau processus. Cet appel système a pour but de copier tous les attributs du processus courant. Le nouveau processus sera donc litérallement le clone de son père et partagent même certaines ressources. Les seules informations que créent vraiment clone() sont les stacks place, il est evident que deux processus ne peuvent pas avoir la même. Lorsque deux processus partagent la même mémoire virtuelle, alors ils fonctionnent comme des threads (voir la section suivante). 3.2 Gestion des threads Page 208 Les plus anciennes versions des noyaux Linux ne supportaient pas le multithreading. Si l on voulait quand même utiliser des threads il fallait passer par des libraires externes à un user level, la librairie la plus célèbre pour les threads étant la libraire pthread (POSIX). La subtilité avec ce procdédé est que Linux fait un sorte que le noyau ne sache pas différencier les threads des processus, ainsi les user-level thread sont mappés en kernel-level process. Tous les processus obtenus de cette façon auront le même user ID, ce qui est logique vu qu ils représentent des threads d un même processus. 12

13 3.3 Mécanismes de concurrence Page Linux inclut tous les mécanismes de concurrence que les autres systèmes UNIX (pipes, messages, etc.) mais en a d autres qui seront détaillés ici Opérations atomiques Des opérations atomiques sont simplement une série d instruction qui peuvent s exécuter sans avoir d interruption ou d interférence ce qui permet d éviter certains cas de race condition. C est encore la technique la plus simple pour protéger les zones critiques, mais ne permet malheureusement pas de faire des choses assez évoluées Spinlocks Les spinlocks sont une technique utilisée pour protéger des sections critiques. Un seul thread à la fois peut avoir un spinlock, tous les autres qui essayent d avoir le même lock vont continuer sans arrêt à essayer de l avoir, on dit qu ils sont dans un état "spinning". L avantage du spinlock est qu il est facile à implémenter, mais en contre partie les spinning threads continuent à s exécuter dans un busy wait mode. C est pourquoi on utilise les spinlocks que lorsqu on sait que les temps d acquisition des locks sera assez court Barriers Une barrière est un type de synchronisation qui oblige un groupe de processus ou de threads à stopper leur exécution à un certain endroit jusqu à ce que tous les autres threads/processus atteignent eux aussi un certain point d exécution. 3.4 Gestion de la mémoire Page Linux partage beaucoup de caractéristiques avec le modèle de gestion de mémoire de UNIX mais a aussi ses propres fonctionnalités. En fait, la gestion de mémoire est quelque chose de très compliquée dans linux, du coup on ne parlera que des aspects principaux, le process virtal memory et le kernel memory allocation Process virtual memory Virtual memory addressing chacun en un type de page. Linux utilise une structure de page à trois niveaux qui consistent 1. Page directory : Un processus actif a une seule page directory qui est de la taille d une page. Chaque entrée dans cette table pointe sur une page dans le page middle directory. La page directory doit absolument être dans la main memory pour un processus actif. 2. Page middle directory : Cette table peut s étendre sur plusieurs pages. Chaque entrée pointe sur une page dans la page table. 3. Page table : Cette table peut s étendre sur plusieurs pages. Chaque entrée de cette table référence une page virtuelle du processus. 4. Page frame in physical memory : Ne correspond pas à un niveau particulier, mais à partir de la page table et d un offset présent dans l adresse virtuelle de la page dans la mémoire physique. Pour pouvoir utiliser ce schéma à trois niveaux, il faut que l adresse virtuelle soit constituée de quatre champs, chacun servant à avoir un index sur une table Le champs le plus à gauche pour la page directory, et celui le plus à droite pour la page frame dans la mémoire physique. 13

14 Page allocation Pour améliorer l efficacité de la lecture/écriture de pages dans/depuis la main memory, Linux utilise un buddy algorithme 15. Page replacement algorithm L algorithme de remplacement se base sur le clock algorithm avec une petite subtilité. Dans l algorithme classique un use bit et un modify bit sont associées à chaque page dans la main memory. Dans Linux, le use bit est remplacé par une variable age de 8-bit, où chaque fois qu une page est accédée, la variable age augmente. Par ailleurs en fonction du temps la variable âge décroit. Un âge grand signifie que la page a souvent été utilisée récemment et n est donc pas éligible à un remplacement tandis qu un âge à faible valeur signifie que la page n a plus été souvent utilisée et peut donc être remplacée Kernel memory allocation Le kernel memory allocation est capable de gérer la physical main memory page frames. Son but principal est d allouer ou de désallouer des frames. Le principe de gestion de page allocation est le même que pour la mémoire virtuelle expliquée énoncée plus haut. 3.5 Scheduling Page Les linux antérieurs au 2.4 avaient deux types de scheduler, un temps réel et un non temps réel assez proche de celui des vieux UNIX. Depuis la 2.6, Linux a gardé essentiellement le même genre de scheduler non réel, mais a complètement changé son scheduler non temps réel. C est de ces deux scheduler que va parler cette section Real-time scheduling Les différents threads sont répartis en trois classes : SCHED_FIFO : des threads temps réels de scheduling FIFO. SCHED_RR : des threads temps réels de scheduling round-robin. SCHED_OTHER : des threads non temps réels d autres types de scheduling Il va de soit que les threads temps réels ont une plus grande priorité que les autres 16. Les règles que suivent tous ces threads sont assez classiques. Par exemple pour un thread FIFO, on a ces quelques règles : 1. Le système ne peut pas interrompre un thread FIFO sauf dans trois situations précises : Un thread FIFO d un priorité plus élevée devient prêt à être exécuté. Dans ce cas, celui en running state est préempté et laisse la place à l autre 17. Le thread FIFO en train d être exécuté est bloqué par un événement particulier. Le thread demande volontairement à se retirer via l appel sched_yield. 2. Quand un thread FIFO est interrompu, il est placé dans la queue en gardant sa priorité. Pour les threads round-robin, c est similaire en tenant compte du timeslice propre à ce scheduling. Les threads de la classe sched_other quant à eux, ne peuvent s exécuter que s il n y a aucun thread temps-réel prêt à l exécution Non real time scheduling Le scheduler pour Linux 2.4 devenait petit à petit inefficace à cause de l augmentation du nombre de processeurs et de processus. C est pourquoi on a décidé de renouveler tout ça avec Linux 2.6. Ce système utilise un nouveau type de scheduler connu sous le nom de O(1) scheduler. 15. Je ne connais pas ce truc, je n explique donc pas plus mais je ne pense pas que ce soit utile à connaître La priorité des temps réels à une valeur de 0 à 99 contre 100 à 139 pour les autres. 17. S il y en a plusieurs de même priorité, c est celui qui a attendu le plus longtemps qui est pris. 14

15 Ce scheduler est capable de calculer quel processus mettre à quel processeur en un temps constant, quelque soit le nombre de processeurs du système. Par ailleurs une queue de priorité est associée à chaque niveau de priorité 18 pour chaque processeur. Cette assignation de queues se fait en double, on a ainsi les queues correspondant aux queues actives où sont mis les threads qui ont été préempté et les queues relatives à l expired queues où sont mis les threads qui ont accomplis leur timeslice. Le scheduling se fait à partir de l active queue, et une fois que cette dernière est vide, on switch tous les threads de l expired queue relative dedans, et c est reparti. Le scheduler regarde aussi de temps en temps si la répartition des tâches se fait bien au niveau des processeurs 19 et règle ça dans le cas échéant. 3.6 I/O Management Page 529 et 532 L I/O management est assez similaire à celle de UNIX SVR4, où un fichier spécial est attribué à chaque dispositif I/O. Juste quelques améliorations sont apportées dont une concernant la page cache Linux page cache Dans les versions antérieures à Linux 2.2 le kernel maintenait d une part, une page cache pour les lectures/écritures des fichiers du file system et pour les virtual memory page, et d autre part un buffer cache pour les block I/O. Depuis Linux 2.4, il n y a plus qu une seule page cache unifiée qui est impliquée dans le trafic entre les disques et la main memory. L utilisation d une cache confère deux grands avantages : 1. Lorsqu on veut réécrire sur une dirty page sur le disque, ces dernières peuvent être bien ordonnées dans la cache et donc écrites efficacement. 2. A cause du principe le localité temporelle, les pages dans la page cache ont plus de chance d être référencée plusieurs fois après avoir été mises dans la cache ce qui évite de devoir faire une opération I/O. Définition 3.1 (Dirty page). Une dirty page est une page qui a été modifiée et qui n existe plus dans le paging file, On doit donc écrire la nouvelle dans le disque pour remplacer l ancienne. Généralement on écrit les dirty pages sur le disque dans deux situations, soit quand le nombre de dirty page dépasse un certain seuil, et dans ce cas ces pages sont écrite sur le disque, soit quand la mémoire libre tombe en dessous d un certain seuil. 3.7 Disk scheduling Page Dans Linux 2.4 l algorithme de disk scheduler était le Linux Elevator qui était une variation de l algorithme SCAN/LOOK. Depuis Linux 2.6, l algorithme Elevator a été amélioré de deux autres algorithmes, le "deadline I/O scheduler" et le "anticipatory I/O scheduler" Elevator scheduler Cet algorithme correspond assez fort à l algorithme SCAN. Il maintient dans un premier temps une queue pour les requêtes d écriture ou de lecture sur le disque et effectue des fonction de tri et de fusion au sein même de la queue. Ainsi, l elevator scheduler a une liste des requêtes qui sont triées par leur numéro de bloc 20. Par ailleurs, une fois que les requêtes du disque sont dans la liste, la tête de lecture du disque commence à bouger mais seulement dans une seule direction, 18. La valeur par défaut est de Il regarde si l un n est pas surchargé pendant qu un autre ne fout rien quoi. 20. Concrètement, ce tri est fait par la localisation des blocs sur le disque, des données proches seront dans le même bloc. 15

16 en satisfaisant toutes les requêtes qu il peut effectuer dans son mouvement. Quand une nouvelle requête est ajoutée dans la queue, quatre opérations sont considérées dans cet ordre : 1. Si la requête est dans le même secteur du disque ou dans un directement adjacent à une requête en attente dans la queue, alors les deux requêtes sont fusionnées en une. 2. S il y a une requête dans la queue qui est plus vieille qu un certain seuil défini, alors la nouvelle requête est insérée tout à la fin. Cela est prévu pour éviter la starvation. 3. Si l endroit de la requête est approprié par rapport à la position de la tête de lecture, alors la nouvelle requête est insérée à un endroit adéquat dans la liste. 4. Si l endroit de la requête est inapproprié par rapport à la position de la tête de lecture, alors la nouvelle requête est insérée en fin de queue Deadline I/O scheduler Cette amélioration règle deux gros problèmes de l elevator scheduler. Le premier concerne la starvation. On a vu que l elevator scheduler faisait un test pour éviter la starvation (Point 2 des opérations), mais celui ci ce fait avant un autre (Point 1). Ainsi, même si la starvation n arrive pas, il se peut qu une requête doive attendre extrêmement longtemps avant d être traitée si on crée sans arrêt de nouvelles requêtes utilisant le secteur ou se trouve la tête de lecture. Un deuxième problème plus important vient du fait qu on ne fait pas la distinction entre les requêtes de lecture et d écriture. En effet, lorsqu un processus effectue une requête d écriture sur un disque, il n a pas forcément besoin d attendre que la requête soit finie, on met sa requête dans un buffer puis le processus continue à vaguer à ses occupation. Tandis que pour une requête de lecture, le processus doit attendre le résultat avant de continuer, on voit alors l intérêt de séparer les requêtes de lecture et d écriture. Dans l elevator, vu qu on tenait pas compte de ça, les processus devaient attendre que les requêtes d écriture soient terminées et donc d attendre, et cela cumulé avec le risque de starvation peut provoquer des performances désastreuses. Pour régler cela, le deadline I/O scheduler utilise trois queues dont la classique elevator queue qui fonctionne comme précédemment et où vont toutes les nouvelles requêtes. Par ailleurs, les mêmes requêtes placées dans l elevator queue sont aussi placées soit dans une Read FIFO queue soit dans une Write FIFO queue 21. Comme ces deux queues sont FIFO, elles gardent les requêtes suivant l ordre dans lequel elles sont faites. On associe aussi à chaque requête un temps d expiration qui est sensiblement plus grand pour une requête d écriture 22 Quand une requête est finie, elle est retirée des deux queues correspondantes. La subtilité dans cette technique réside dans le fait que si une requête située en tête de sa queue FIFO relative est plus vieille que son temps d expiration, alors le scheduler prend la requête expirée ainsi que les quelques suivantes dans la queue 23. Grâce à cette structure on règle les deux problèmes de l algorithme précédent Anticipatory I/O scheduler Une autre amélioration à l elevator peut être apportée. En effet, pour l instant cet algorithme, même amélioré avec le deadline scheduler, est conçu pour traiter une nouvelle requête dès que la requête existante est finie, afin de s assurer que le disque soit occupé le plus possible. Mais imaginons qu un processus veuille faire plusieurs opérations de lectures synchrones 24, le temps que la réponse de la première lecture soit envoyée au processus et que la deuxième soit envoyée au disque, d autres requêtes peuvent être traitées entre-temps, ce qui met notre opération dans la queue et ce qui laisse le temps à la tête de lecture de changer de place. L anticipatory scheduler tente de régler ça. Lorsqu une requête est dispatchée de la queue, l anticipatory scheduler crée un petit temps de latence durant lequel les requêtes ne peuvent pas être traitées sauf celles venant de l application qui a lancé la requête précédente. Une fois ce temps 21. Vous aurez compris quel type de requêtes gardent ces queues une demi seconde pour une requête de lecture contre cinq pour une d écriture. 23. Toutes ces requêtes dispatchées sont bien sûr retirée de l elevator queue. 24. C est à dire que la deuxième ne pourra s exécuter que lorsqu une réponse de la première a été reçue. 16

17 de latence passé, c est un deadline scheduler qui est repris. Les tests montrent que l utilisation d un anticipatory scheduler augmente drastiquement les performances des I/O. 4 Windows 4.1 Gestion des processus et des threads Page Les Processus et les threads étant assez liés dans Windows, je détaillerai ces deux notions en parallèle Caractéristiques des processus Windows implémente les processus et les threads d une façon assez différentes que les autres systèmes. Voici les caractérisques principales des processus dans Windows : Les processus et les threads sont implémentés comme objets. L utilité d utiliser des objets est que ces derniers sont bien encapsulés des autres. Evidemment tous leurs attributs font partie intégrante de l objet. Un processus peut être créé comme un nouveau processus ou comme une copie d un processus existant. Un processus exécutable peut et doit contenir un ou plusieurs threads. Les processus et les threads ont des capacités intrinsèques de synchronisation. A chaque processus est assigné un acces token qui sert à gérer les accès des différents objets. Chaque processus a une série de blocs qui définissent les adresses virtuelles assignées au processus. Chaque processus a une tables des objets qui garde tous les objets connus pour ce processus comme les différents threads, des fichiers, etc Multithreading Le multithreading est assez efficace sur Windows, en effet, plusieurs threads du même processeur peuvent être exécuté en parallèle sur différents processeurs. Par ailleurs les threads d un même processeur peuvent facilement communiquer entre eux grâce aux aux address space qu ils ont en commun et ont chacun accès aux ressources du processus. Les threads de différents processus peuvent aussi communiquer entre eux par le biais des ressources partagées entre plusieurs processus Etats des threads Ready. Standby : Le thread a été sélectionné pour être exécuté sur un processeur particulier. Il attend dans cet état jusqu à ce que le processeur soit disponible. Ce thread peut aussi être préemptif par rapport à celui déjà exécuté par le processeur. Running. Waiting. Transition : Un thread entre dans cet état après un waiting s il est prêt mais que les ressources ne sont pas disponibles. Terminated. Ces états sont assez classiques par rapport à ceux généraux Contrôle des processus et des threads On s est tous déjà demandé pourquoi les programmes Windows ne sont jamais compatibles sans faire milles manipulations avec les autres systèmes comme Linux. Le réponse vient du fait que l implémentation des processus et des threads est complètement différente des autres systèmes et aussi bien plus compliquée, ce qui fait qu on doit passer par un émulateur si l on veut faire tourner des programmes Windows sur d autres systèmes. 17

18 4.2 Mécanismes de concurrence Page Dans Windows, les méthode de synchronisation font partie intégrante de l architecture des objets Dispatcher objects Windows a toute une série d objet, les dispatcher objects, prévus spécialement pour supporter les synchronisations. La famille de ces objets est détaillée à la page 315. Chaque dispatcher object a une fonction bien particulière et s utilise dans une situation bien précise User-mode critical section Donne un mécanisme similaire à ceux fournis par les mutex à la différence qu une section critique peut être atteinte que par des threads d un seul processus Slim reader-writer locks Voir la section sur Solaris qui explique ce que c est. Mécanisme ajouté à Windows Vista 25 qui ajoute un mode utilisateur "reader-writer". Sert globalement à protéger des zones critiques Conditions variables Voir la section sur Solaris qui explique ce que c est. Les conditions variables se cumulent généralement avec critical section où les SLW locks. Ce mécanisme a différentes méthodes qui permettent d acquérir un lock, de le relâcher, de réveiller un threadn etc. Elles sont surtout utilisées pour avoir un lock exclusif, faire des opérations protégées et libérer un lock Lock free operations Autre méthode qui a l avantage qu un thread ne peut jamais être switché en dehors d un processeur. On ne bloque jamais un thread en état running. 4.3 Gestion de la mémoire Page Le Windows virtual memory manager contrôle comment la mémoire est allouée et comment le paging est effectué Windows virtual adress map Dans un Windows 32 bits, chaque processus voir une address space de 32 bits constitué des parties suivantes 26 : Une partie peu volumineuse pour aider les programmeurs à catcher les NULL pointers assigment. L available user adress space, qui est divisé en page qui peuvent être chargées dans la main memory. Cette partie fait 2 Gigabytes. Une autre partie peu volumineuse qui est inaccessible à l utilisateur. Cette page facile l OS à trouver lees bad pointers assigment. Le system adress space, inaccessible à l utilisateur. Cette partie fait 2 Gigabytes. 25. Oui oui, vous pensez déjà que cette méthode est foireuse! 26. Pour des systèmes 64-bits, la taille n est pas la même. 18

19 4.3.2 Windows paging Quand un processus est créé, il peut en principe utilisé l entièreté de l espace utilisateur de 2 Gb. Cette espace est divisé en page, chacune pouvant être amenée dans la main memory, mais l OS met les adresses dans des régions contiguës allouées de 64 Kb. Une région peut avoir trois états : Available : Adresses non utilisées par le processus. Reserved : Adresses que le virtual memory manager à réservée pour un processus et qui ne peut donc pas être allouée pour un autre usage. Committed : Adresses que le virtual memory manager a initialisé pour une utilisation par un processus qui veut accéder à la virtual memory page Windows resident set management La stratégie de resident set management est à allocation variable et de portée locale. 4.4 Scheduling Page Windows est conçu pour être le plus réceptif possible aux besoins du simple utilisateur dans un système hautement interactif ou quand il a le rôle de serveur. Il implémente un scheduler préemptif avec un système flexible de niveau de priorité qui inclut un scheduling round-robin dans chaque niveau. Pour certains niveaux particuliers, on calcule dynamiquement les priorités en se basant sur l activité des threads. Dans Windows, ce sont plus les threads que les processus qui sont "l unité" de scheduling. Attention que sur windows une valeur de priorité grande signifie que la priorité effective est grande, contrairement aux autres systèmes! Priorité des processus et des threads Les priorités sont organisées en deux bandes, les temps réels et les variables. Chaque bande contient 16 niveau de priorité. Les priorités et les préemptions se font de manière classiques 27 et on a une queue FIFO à chaque niveau de priorité. Cependant, suivant la classe la manière de donner les priorités varie. Dans la bande temps réels, les threads ont une priorité fixée qui ne change jamais et dans la classe variable, les threads ont une priorité initiale qui peut être augmentée au cours de la durée de vie du thread. Cette propriété initiale est déterminée par deux valeurs, la priorités du processus contenant le thread et la priorité du thread relative à celle du processus. Après, on peut changer dynamiquement la priorité de ces threads. La figure de la page 487 illustre bien la situation Multiprocessor scheduling Quand windows est lancé avec un seul processeur,c est évidemment le thread le plus prioritaire qui est actif, sauf s il attend un événement. Si plusieurs threads ont la même priorité le processeur est partagé avec une politique round robin avec tous les threads de cette priorité. Dans un système multiprocesseur, le noyau distribue aux N processeurs les N threads les plus prioritaires prêts à l emploi. Les threads les moins prioritaires doivent attendre, et peuvent être boostés s ils commencent à avoir faim 28. Ce scheduling tient compte par ailleurs de l affinité du processeur. 4.5 I/O Management Page Les plus prioritaires préemptent les autres blablabla. 28. Oui c était pourri. 19

20 4.5.1 Basic I/O facilities Dans Windows, c est l I/O manager qui est le responsable de toutes les opérations I/O du système et il fournit aussi une interface uniforme que tous les types de driver peuvent utiliser. L I/O manager travaille surtout avec quatre types de composant du noyau : Cache manager : Il s occupe de la mise en mémoire cache pour tous les file systems. Il peut dynamiquement adapter la taille d une cache associée à un fichier particulier en fonction de la mémoire physique disponible. Par ailleurs, le système enregistre les mises à jours uniquement dans la cache et pas dans les disque, c est un kernel thread, programmé en lazy, qui va périodiquement insérer ces mises à jour dans le disque. Plus précisément, le cache manager fonctionne en mappant des groupes de fichiers dans le kernel virtual memory, le plus gros du boulot étant laisser au virtual memory manager qui doit copier les page dans/depuis les disques. File system driver : L I/O manager traite les file system drivers comme n importe quels autres device drivers et il envoie les données 29 au driver approprié aux données. Network drivers : Windows comporte des fonctionnalités intégrées de networking ainsi qu un support pour les systèmes de fichiers distants. Ces fonctionnalités sont implémentées comme des drivers software et non au sein du Windows Executive. Hardware device drivers : Ces drivers software peuvent accéder aux registres hardwares des dispositifs périphériques. Cela est présent dans toutes les plateformes supportées par Windows. Par ailleurs, comme les fonctions implémentant cela ont des caractéristiques identiques, le code source des devices drivers de Windows sont portables sur différents types de processeurs Types d I/O Il y a deux grands types d I/O dans windows les synchrones et les asynchrones. I/O synchrone Le mode synchrone est utilisé lorsqu un processus est obligé d attendre le résultat de son appel I/O avant de pouvoir poursuivre sont exécution. Ce mode est typiquement utilisé pour des opérations de lecture. I/O asynchrone Le mode asynchrone est utilisé lorsqu un processus peut directement continuer son exécution après avoir lancé son opération I/O. Ce mode est utilisé le plus souvent possible de part les meilleures performances qu elle apporte par rapport au mode synchrone. Cependant, l application qui a invoqué l opération I/O a besoin à un moment ou un autre de savoir quand l opération est complète. Windows fournit cinq techniques différentes pour cela : Signaling the file object : Cette technique permet d associer un événement à un file object 30 lorsque l opération sur l objet est finie. Ainsi, un thread qui a fait une opération I/O peut continuer son exécution jusqu à ce qu il arrive à un point où il doit attendre que l opération I/O soit finie. Là le thread attend que l événement lui soit associé pour dire que l opération I/O est finie et il peut donc là continuer son exécution. Le problème est que cette technique de marche pas pour des multiples requêtes I/O. Signaling an even object : Ici un événement est créé pour chaque requête, ce qui permet de gérer les requêtes multiples. 29. Volumes en anglais. 30. Donc à un thread où à un processus par exemple. 20