Mach (noyau) - Mach (kernel)

Mach
Développeur(s) Richard Rashid
Avie Tevanian
Première version 1985 ; il y a 36 ans ( 1985 )
Version stable
3.0 / 1994 ; il y a 27 ans ( 1994 )
Taper Micronoyau
Site Internet Le projet Mach

Mach ( / m ɑː k / ) est un noyau développé à l' Université Carnegie Mellon par Richard Rashid et Avie Tevanian et dérivés à l' origine de 4.3BSD pour soutenir le système d' exploitation de recherche, principalement distribués et calcul parallèle . Mach est souvent mentionné comme l'un des premiers exemples de micronoyau . Cependant, toutes les versions de Mach ne sont pas des micronoyaux. Les dérivés de Mach sont à la base du noyau du système d'exploitation dans GNU Hurd et de pomme de XNU noyau utilisé dans macOS , iOS , iPadOS , tvOS et watchos .

Le projet de Carnegie Mellon s'est déroulé de 1985 à 1994, se terminant par Mach 3.0, qui est un véritable micronoyau . Mach a été développé pour remplacer le noyau dans la version BSD d' Unix , donc aucun nouveau système d'exploitation ne devrait être conçu autour de lui. Mach et ses dérivés existent dans un certain nombre de systèmes d'exploitation commerciaux. Celles-ci incluent toutes l'utilisation du noyau du système d'exploitation XNU qui incorpore un Mach antérieur non micro-noyau en tant que composant majeur. Le système de gestion de mémoire virtuelle Mach a également été adopté dans 4.4BSD par les développeurs BSD du CSRG et apparaît dans les systèmes Unix modernes dérivés de BSD, tels que FreeBSD .

Mach est le successeur logique du noyau Accent de Carnegie Mellon . Le développeur principal du projet Mach, Richard Rashid , travaille chez Microsoft depuis 1991 ; il a fondé la division Microsoft Research . Un autre des développeurs originaux de Mach, Avie Tevanian , était auparavant responsable des logiciels chez NeXT , puis directeur de la technologie logicielle chez Apple Inc. jusqu'en mars 2006.

Histoire

Nom

Alors que les développeurs, une fois au cours de la phase de désignation, a dû vélo pour le déjeuner à travers les flaques de boue de pluie Pittsburgh, Tevanian a plaisanté le mot « muck » pourrait servir backronym pour leur M ulti- U ser (ou M ultiprocessor U niversal) C ommunication K ernel. L'ingénieur italien CMU Dario Giuse a ensuite interrogé le chef de projet Rick Rashid sur le titre actuel du projet et a reçu "MUCK" comme réponse, bien que non épelé mais simplement prononcé comme IPA:  [mʌk] qu'il, selon l' alphabet italien , a écrit comme Mach . Rashid aimait tellement l'orthographe de Giuse "Mach" qu'elle l'a emporté.

tuyaux Unix

Un concept clé dans le système d'exploitation Unix original était l'idée d'un tuyau . Un tube était une abstraction qui permettait de déplacer des données sous forme de flux non structuré d'octets d'un programme à l'autre. À l'aide de tuyaux, les utilisateurs (ou les programmeurs) peuvent relier plusieurs programmes pour accomplir des tâches, en alimentant tour à tour les données via plusieurs petits programmes. Cela contrastait avec les systèmes d'exploitation typiques de l'époque, qui nécessitaient un seul programme volumineux capable de gérer l'ensemble de la tâche, ou, alternativement, utilisaient des fichiers pour transmettre des données, ce qui était coûteux en ressources et prenait beaucoup de temps.

Les tuyaux ont été construits sur le système d' entrée/sortie sous-jacent . Ce système était, à son tour, basé sur un modèle où les conducteurs devaient périodiquement "bloquer" pendant qu'ils attendaient la fin des tâches. Par exemple, un pilote d'imprimante peut envoyer une ligne de texte à une imprimante ligne et n'avoir rien à faire jusqu'à ce que l'imprimante ait terminé d'imprimer cette ligne. Dans ce cas, le pilote indiquerait qu'il était bloqué et le système d'exploitation permettrait à un autre programme de s'exécuter jusqu'à ce que l'imprimante indique qu'elle est prête pour plus de données. Dans le système de tuyaux, la ressource limitée était la mémoire, et lorsqu'un programme remplissait la mémoire affectée au tuyau, il se bloquait naturellement. Normalement, cela entraînerait l'exécution du programme consommateur, vidant à nouveau le tuyau. Contrairement à un fichier, où l'intégralité du fichier doit être lu ou écrit avant que le programme suivant puisse l'utiliser, les canaux ont fait en sorte que le mouvement des données entre plusieurs programmes se produise de manière fragmentée sans aucune intervention du programmeur.

Cependant, la mise en œuvre de tuyaux en tant que tampons mémoire signifiait que les données étaient copiées d'un programme à l'autre, une opération longue et consommatrice de ressources. Cela rendait le concept de pipe inadapté aux tâches nécessitant un délai d'exécution rapide ou une faible latence, comme c'est le cas dans la plupart des pilotes de périphérique . Le noyau du système d'exploitation et la plupart des fonctionnalités de base ont plutôt été écrits sous la forme d'un seul grand programme. Au fur et à mesure que le système d'exploitation ajoutait de nouvelles fonctionnalités ( réseau informatique , par exemple), la taille et la complexité du noyau augmentaient également.

Nouveaux concepts

Les tuyaux Unix offraient un système conceptuel qui pouvait être utilisé pour créer des solutions arbitrairement complexes à partir de petits programmes en interaction. Étant plus petits, ces programmes étaient faciles à programmer et à entretenir, et avaient des interfaces bien définies qui simplifiaient la programmation et le débogage. Ces qualités sont encore plus précieuses pour les pilotes de périphériques, où la petite taille et les performances sans bogue sont extrêmement importantes. Il y avait un fort désir de modéliser le noyau lui-même sur la même base de petits programmes interactifs.

L'un des premiers systèmes à utiliser un système de type pipe comme base du système d'exploitation était le noyau Aleph développé à l' Université de Rochester . Cela a introduit le concept de ports , qui étaient essentiellement une implémentation de mémoire partagée . Dans Aleph, le noyau lui-même était réduit à fournir un accès au matériel, y compris la mémoire et les ports, tandis que les programmes conventionnels utilisant le système de ports implémentaient tous les comportements, des pilotes de périphériques aux programmes utilisateur. Ce concept a considérablement réduit la taille du noyau et a permis aux utilisateurs d'expérimenter différents pilotes simplement en les chargeant et en les connectant ensemble au moment de l'exécution. Cela a grandement facilité les problèmes lors du développement du nouveau code du système d'exploitation, qui autrement nécessitait généralement le redémarrage de la machine. Le concept général d'un petit noyau et de pilotes externes est devenu connu sous le nom de micro-noyau.

Aleph a été implémenté sur les mini-ordinateurs Data General Eclipse et y était étroitement lié. Cette machine était loin d'être idéale, car elle nécessitait de copier de la mémoire entre les programmes, ce qui impliquait une surcharge de performances considérable. C'était aussi assez cher. Néanmoins, Aleph a prouvé que le système de base était solide et a continué à démontrer le clustering d'ordinateurs en copiant la mémoire sur une première interface Ethernet .

À cette époque, une nouvelle génération de processeurs centraux (CPU) arrivait sur le marché, offrant des espaces d'adressage 32 bits et (initialement facultatif) la prise en charge d'une unité de gestion de la mémoire (MMU). La MMU gérait les instructions nécessaires à la mise en œuvre d'un système de mémoire virtuelle (VM) en gardant une trace des pages de mémoire utilisées par divers programmes. Cela offrait une nouvelle solution au concept de port, en utilisant le mécanisme de copie sur écriture utilisé par VM . Au lieu de copier les données entre les programmes, il suffisait d'envoyer les données nécessaires pour demander à la MMU de fournir un accès à la même mémoire. Ce système mettrait en œuvre le système de communication interprocessus avec des performances considérablement plus élevées.

Ce concept a été repris par Carnegie-Mellon, qui a adapté Aleph pour le poste de travail PERQ et l'a mis en œuvre en utilisant la copie sur écriture. Le portage a réussi, mais le noyau Accent résultant était d'une utilisation pratique limitée car il n'exécutait pas les logiciels existants. De plus, Accent était aussi étroitement lié à PERQ qu'Aleph l'était à l'Eclipse.

Mach

Le changement majeur entre ces noyaux expérimentaux et Mach a été la décision de faire une version du noyau 4.2BSD existant réimplémenté sur les concepts de passage de messages Accent. Un tel noyau serait binairement compatible avec les logiciels BSD existants, rendant le système immédiatement utile pour une utilisation quotidienne tout en restant une plate-forme expérimentale utile. De plus, le nouveau noyau serait conçu dès le départ pour prendre en charge plusieurs architectures de processeurs, permettant même la construction de clusters hétérogènes. Afin de mettre le système en place le plus rapidement possible, le système serait mis en œuvre en commençant par le code BSD existant et en le réimplémentant petit à petit en tant que programmes basés sur la communication inter-processus (basés sur IPC). Ainsi, Mach commencerait comme un système monolithique similaire aux systèmes UNIX existants, et évoluerait davantage vers le concept de micronoyau au fil du temps.

Mach a commencé en grande partie comme un effort pour produire un Accent clairement défini, basé sur UNIX et hautement portable. Le résultat est une courte liste de concepts génériques :

  • une " tâche " est un objet constitué d'un ensemble de ressources système qui permettent l'exécution de " threads "
  • un " thread " est une unité d'exécution unique, existe dans le contexte d'une tâche et partage les ressources de la tâche
  • un " port " est une file d' attente de messages protégée pour la communication entre les tâches ; les tâches possèdent des droits d'envoi (autorisations) et des droits de réception sur chaque port.
  • Les " messages " sont des collections d'objets de données typés, ils ne peuvent être envoyés qu'aux ports, pas spécifiquement aux tâches ou aux threads

Mach s'est développé sur les concepts IPC d'Accent, mais a rendu le système beaucoup plus de nature UNIX, capable même d'exécuter des programmes UNIX avec peu ou pas de modification. Pour ce faire, Mach a introduit le concept de port , représentant chaque point de terminaison d'un IPC bidirectionnel. Les ports avaient une sécurité et des droits comme les fichiers sous UNIX, permettant de leur appliquer un modèle de protection très similaire à UNIX. De plus, Mach autorisait n'importe quel programme à gérer les privilèges qui seraient normalement accordés au système d'exploitation uniquement, afin de permettre aux programmes de l' espace utilisateur de gérer des choses comme l'interaction avec le matériel.

Sous Mach, et comme UNIX, le système d'exploitation redevient principalement un ensemble d'utilitaires. Comme avec UNIX, Mach conserve le concept de pilote pour gérer le matériel. Par conséquent, tous les pilotes pour le matériel actuel doivent être inclus dans le micronoyau. D'autres architectures basées sur la couche d'abstraction matérielle ou les exokernels pourraient déplacer les pilotes hors du micronoyau.

La principale différence avec UNIX est qu'au lieu d'utilitaires gérant les fichiers, ils peuvent gérer n'importe quelle "tâche". Davantage de code du système d'exploitation a été déplacé du noyau vers l'espace utilisateur, ce qui a entraîné un noyau beaucoup plus petit et l'apparition du terme microkernel . Contrairement aux systèmes traditionnels, sous Mach, un processus, ou "tâche", peut consister en un certain nombre de threads. Bien que cela soit courant dans les systèmes modernes, Mach a été le premier système à définir les tâches et les threads de cette manière. Le travail du noyau a été réduit d'être essentiellement le système d'exploitation à la maintenance des "utilitaires" et à la planification de leur accès au matériel.

L'existence de ports et l'utilisation d'IPC sont peut-être la différence la plus fondamentale entre Mach et les noyaux traditionnels. Sous UNIX, l'appel du noyau consiste en une opération appelée appel système ou trap . Le programme utilise une bibliothèque pour placer des données dans un emplacement bien connu de la mémoire et provoque alors un défaut , un type d'erreur. Lorsque le système est démarré pour la première fois, le noyau est configuré pour être le "gestionnaire" de tous les défauts, donc lorsque le programme provoque un défaut, le noyau prend le relais, examine les informations qui lui sont transmises, puis exécute les instructions.

Sous Mach, le système IPC a été utilisé pour ce rôle à la place. Afin d'appeler la fonctionnalité du système, un programme demanderait au noyau d'accéder à un port, puis utiliserait le système IPC pour envoyer des messages à ce port. Bien que les messages aient été déclenchés par des appels système comme ils le seraient sur d'autres noyaux, sous Mach, c'était à peu près tout ce que le noyau faisait - la gestion de la demande réelle appartiendrait à un autre programme.

La prise en charge des threads et de la concurrence a bénéficié de la transmission de messages avec des mécanismes IPC, car les tâches consistaient désormais en plusieurs threads de code que Mach pouvait geler et dégeler pendant la gestion des messages. Cela a permis au système d'être distribué sur plusieurs processeurs, soit en utilisant la mémoire partagée directement comme dans la plupart des messages Mach, soit en ajoutant du code pour copier le message sur un autre processeur si nécessaire. Dans un noyau traditionnel, c'est difficile à mettre en œuvre ; le système doit s'assurer que différents programmes n'essaient pas d'écrire dans la même mémoire à partir de différents processeurs. Cependant, les ports Mach, son processus d'accès à la mémoire, rendent cela bien défini et facile à mettre en œuvre, et sont devenus un citoyen de première classe dans ce système.

Le système IPC avait initialement des problèmes de performances, donc quelques stratégies ont été développées pour minimiser l'impact. Comme son prédécesseur, Accent , Mach utilisait un seul mécanisme de mémoire partagée pour transmettre physiquement le message d'un programme à un autre. Copier physiquement le message serait trop lent, donc Mach s'appuie sur l' unité de gestion de mémoire (MMU) de la machine pour mapper rapidement les données d'un programme à un autre. Ce n'est que si les données sont écrites qu'elles devraient être physiquement copiées, un processus appelé " copie sur écriture ".

La validité des messages a également été vérifiée par le noyau, afin d'éviter que de mauvaises données ne fassent planter l'un des nombreux programmes constituant le système. Les ports ont été délibérément modelés sur les concepts du système de fichiers UNIX. Cela a permis à l'utilisateur de trouver des ports à l'aide des concepts de navigation du système de fichiers existants, ainsi que d'attribuer des droits et des autorisations comme ils le feraient sur le système de fichiers.

Le développement dans un tel système serait plus facile. Non seulement le code sur lequel on travaille existerait dans un programme traditionnel qui pourrait être construit à l'aide d'outils existants, mais il pourrait également être démarré, débogué et arrêté à l'aide des mêmes outils. Avec un mononoyau, un bogue dans le nouveau code entraînerait l'arrêt complet de la machine et nécessiterait un redémarrage, alors que sous Mach, cela nécessiterait uniquement le redémarrage du programme. De plus, l'utilisateur peut adapter le système pour inclure ou exclure toutes les fonctionnalités dont il a besoin. Étant donné que le système d'exploitation n'était qu'une collection de programmes, ils pouvaient ajouter ou supprimer des parties en les exécutant ou en les supprimant simplement comme ils le feraient avec n'importe quel autre programme.

Enfin, sous Mach, toutes ces fonctionnalités ont été délibérément conçues pour être extrêmement neutres sur la plate-forme. Pour citer un texte sur Mach :

Contrairement à UNIX, qui a été développé sans tenir compte du multitraitement, Mach intègre la prise en charge du multitraitement partout. Sa prise en charge du multitraitement est également extrêmement flexible, allant des systèmes à mémoire partagée aux systèmes sans mémoire partagée entre les processeurs. Mach est conçu pour fonctionner sur des systèmes informatiques allant d'un à des milliers de processeurs. De plus, Mach est facilement transférable sur de nombreuses architectures informatiques variées. Un objectif clé de Mach est d'être un système distribué capable de fonctionner sur du matériel hétérogène. ( Annexe B , Concepts du système d'exploitation )

Il y a cependant un certain nombre d'inconvénients. Une question relativement banale est qu'il n'est pas clair comment trouver des ports. Sous UNIX, ce problème a été résolu au fil du temps car les programmeurs se sont mis d'accord sur un certain nombre d'emplacements "bien connus" dans le système de fichiers pour remplir diverses fonctions. Alors que cette même approche fonctionnait également pour les ports de Mach, sous Mach, le système d'exploitation était supposé être beaucoup plus fluide, les ports apparaissant et disparaissant tout le temps. Sans un mécanisme pour trouver les ports et les services qu'ils représentent, une grande partie de cette flexibilité serait perdue.

Développement

Mach était initialement hébergé en tant que code supplémentaire écrit directement dans le noyau 4.2BSD existant, permettant à l'équipe de travailler sur le système bien avant qu'il ne soit terminé. Le travail a commencé avec le système Accent IPC/port déjà fonctionnel, et est passé aux autres parties clés du système d'exploitation, aux tâches, aux threads et à la mémoire virtuelle. Au fur et à mesure que des portions étaient terminées, diverses parties du système BSD ont été réécrites pour appeler Mach, et une modification de 4.3BSD a également été apportée au cours de ce processus.

En 1986, le système était complet au point de pouvoir fonctionner seul sur le DEC VAX . Bien que faisant peu de valeur pratique, l'objectif de faire un micronoyau a été réalisé. Cela a été rapidement suivi par des versions sur le PC IBM RT et pour les stations de travail Sun Microsystems 68030 , prouvant la portabilité du système. En 1987, la liste comprenait les machines Encore Multimax et Sequent Balance , testant la capacité de Mach à fonctionner sur des systèmes multiprocesseurs. Une version publique 1 a été faite cette année-là, et la version 2 a suivi l'année suivante.

Pendant tout ce temps, la promesse d'un "vrai" micronoyau n'a pas encore été tenue. Ces premières versions de Mach incluaient la majorité de 4.3BSD dans le noyau, un système connu sous le nom de serveur POE , résultant en un noyau qui était en fait plus grand que l'UNIX sur lequel il était basé. L'idée, cependant, était de déplacer la couche UNIX du noyau vers l'espace utilisateur, où elle pourrait être plus facilement travaillée et même carrément remplacée. Malheureusement, les performances se sont avérées être un problème majeur, et un certain nombre de modifications architecturales ont été apportées afin de résoudre ce problème. De lourds problèmes de licence UNIX tourmentaient également les chercheurs, de sorte que cet effort initial pour fournir un environnement système de type UNIX sans licence a continué à trouver une utilité, bien dans le développement ultérieur de Mach.

Le Mach 3 qui en a résulté est sorti en 1990 et a suscité un vif intérêt. Une petite équipe avait construit Mach et l'avait porté sur un certain nombre de plates-formes, y compris des systèmes multiprocesseurs complexes qui causaient de sérieux problèmes aux noyaux de style plus ancien. Cela a suscité un intérêt considérable sur le marché commercial, où un certain nombre d'entreprises envisageaient de changer de plate-forme matérielle. Si le système existant pouvait être porté pour fonctionner sur Mach, il semblerait qu'il serait alors facile de changer la plate-forme en dessous.

Mach a reçu une augmentation majeure de sa visibilité lorsque l' Open Software Foundation (OSF) a annoncé qu'elle hébergerait les futures versions d' OSF/1 sur Mach 2.5 et enquêtait également sur Mach 3. Mach 2.5 a également été sélectionné pour le système NeXTSTEP et un certain nombre de fournisseurs commerciaux de multiprocesseurs. Mach 3 a conduit à un certain nombre d'efforts pour porter d'autres composants de systèmes d'exploitation pour le micronoyau, y compris le système d' exploitation Workplace d' IBM et plusieurs efforts d' Apple pour créer une version multiplateforme du Mac OS classique .

Les problèmes de performance

Mach était à l'origine destiné à remplacer l'UNIX monolithique classique et, pour cette raison, contenait de nombreuses idées de type UNIX. Par exemple, Mach a utilisé un système d'autorisation et de sécurité calqué sur le système de fichiers UNIX. Étant donné que le noyau était privilégié (s'exécutant dans l' espace noyau ) sur d'autres serveurs et logiciels du système d'exploitation, il était possible que des programmes défectueux ou malveillants lui envoient des commandes qui endommageraient le système, et pour cette raison, le noyau vérifiait la validité de chaque message. . De plus, la plupart des fonctionnalités du système d'exploitation devaient être situées dans des programmes en espace utilisateur, ce qui signifiait qu'il devait y avoir un moyen pour le noyau d'accorder à ces programmes des privilèges supplémentaires, pour fonctionner sur du matériel par exemple.

Certaines des caractéristiques les plus ésotériques de Mach étaient également basées sur ce même mécanisme IPC. Par exemple, Mach était capable de prendre en charge facilement les machines multiprocesseurs. Dans un noyau traditionnel, un travail important doit être effectué pour le rendre réentrant ou interruptible , car des programmes exécutés sur différents processeurs pourraient appeler le noyau en même temps. Sous Mach, les bits du système d'exploitation sont isolés dans des serveurs, qui sont capables de fonctionner, comme n'importe quel autre programme, sur n'importe quel processeur. Bien qu'en théorie le noyau Mach doive également être réentrant, en pratique ce n'est pas un problème car ses temps de réponse sont si rapides qu'il peut simplement attendre et servir les requêtes à son tour. Mach incluait également un serveur capable de transférer des messages non seulement entre les programmes, mais même sur le réseau, ce qui était un domaine de développement intense à la fin des années 1980 et au début des années 1990.

Malheureusement, l'utilisation de l'IPC pour presque toutes les tâches s'est avérée avoir un impact sérieux sur les performances. Les benchmarks sur le matériel de 1997 ont montré que les implémentations UNIX à serveur unique basées sur Mach 3.0 étaient environ 50% plus lentes que UNIX natif.

L'étude de la nature exacte des problèmes de performance a révélé un certain nombre de faits intéressants. L'une était que l'IPC en lui-même n'était pas le problème : il y avait une surcharge associée au mappage de mémoire nécessaire pour le prendre en charge, mais cela n'ajoutait qu'une petite quantité de temps pour passer un appel. Le reste, 80% du temps passé, était dû aux tâches supplémentaires que le noyau exécutait sur les messages. Parmi celles-ci, la vérification des droits de port et la validité des messages étaient les plus importantes. Dans benchmarks sur un 486 DX-50, un appel système UNIX standard a une moyenne de 21 ms à remplir, alors que l'opération équivalente à Mach IPC en moyenne 114μs. Seulement 18 s de cela étaient liés au matériel ; le reste était le noyau Mach exécutant diverses routines sur le message. Étant donné un appel système qui ne fait rien, un aller-retour complet sous BSD nécessiterait environ 40 s, alors que sur un système Mach en espace utilisateur, cela prendrait un peu moins de 500 s.

Lorsque Mach a été utilisé sérieusement pour la première fois dans les versions 2.x, les performances étaient plus lentes que les systèmes d'exploitation monolithiques traditionnels, peut-être jusqu'à 25 %. Ce coût n'était cependant pas considéré comme particulièrement préoccupant, car le système offrait également un support multiprocesseur et une portabilité aisée. Beaucoup ont estimé qu'il s'agissait d'un coût attendu et acceptable à payer. Lorsque Mach 3 a tenté de déplacer la majeure partie du système d'exploitation dans l'espace utilisateur, la surcharge est devenue encore plus élevée : les tests de performance entre Mach et Ultrix sur un MIPS R3000 ont montré un impact sur les performances pouvant atteindre 67 % sur certaines charges de travail.

Par exemple, l'obtention de l'heure système implique un appel IPC au serveur de l'espace utilisateur maintenant l' horloge système . L'appelant se bloque d'abord dans le noyau, provoquant un changement de contexte et un mappage de mémoire. Le noyau vérifie alors que l'appelant dispose des droits d'accès requis et que le message est valide. Si c'est le cas, il existe un autre commutateur de contexte et un mappage de mémoire pour terminer l'appel dans le serveur d'espace utilisateur. Le processus doit ensuite être répété pour renvoyer les résultats, en ajoutant jusqu'à un total de quatre changements de contexte et mappages de mémoire, plus deux vérifications de message. Cette surcharge s'ajoute rapidement à des services plus complexes, où il existe souvent des chemins de code passant par de nombreux serveurs.

Ce n'était pas la seule source de problèmes de performances. Un autre était centré sur les problèmes d'essayer de gérer correctement la mémoire lorsque la mémoire physique était faible et qu'une pagination devait se produire. Dans les systèmes d'exploitation monolithiques traditionnels, les auteurs avaient une expérience directe avec quelles parties du noyau appelaient quelles autres, ce qui leur permettait d'affiner leur pager pour éviter de paginer le code qui était sur le point d'être utilisé. Sous Mach, cela n'était pas possible car le noyau n'avait aucune idée réelle de la composition du système d'exploitation. Au lieu de cela, ils ont dû utiliser une seule solution unique qui ajoutait aux problèmes de performances. Mach 3 a tenté de résoudre ce problème en fournissant un simple téléavertisseur, s'appuyant sur des téléavertisseurs de l'espace utilisateur pour une meilleure spécialisation. Mais cela s'est avéré avoir peu d'effet. Dans la pratique, tous les avantages dont il disposait ont été anéantis par l'IPC coûteux nécessaire pour l'appeler.

D'autres problèmes de performances étaient liés à la prise en charge par Mach des systèmes multiprocesseurs . Du milieu des années 80 au début des années 90, les performances des processeurs de base ont augmenté d'environ 60 % par an, mais la vitesse d'accès à la mémoire n'a augmenté que de 7 % par an. Cela signifiait que le coût d'accès à la mémoire augmentait considérablement au cours de cette période, et puisque Mach était basé sur le mappage de la mémoire entre les programmes, tout "échec de cache" ralentissait les appels IPC.

Solutions potentielles

La surcharge IPC est un problème majeur pour les systèmes Mach 3. Cependant, le concept d'un système d'exploitation multi-serveurs est toujours prometteur, même s'il nécessite encore quelques recherches. Les développeurs doivent veiller à isoler le code dans des modules qui n'appellent pas de serveur à serveur. Par exemple, la majorité du code de mise en réseau serait placée sur un seul serveur, minimisant ainsi l'IPC pour les tâches de mise en réseau normales.

La plupart des développeurs s'en sont plutôt tenus au concept original de POE d'un seul gros serveur fournissant les fonctionnalités du système d'exploitation. Afin de faciliter le développement, ils ont permis au serveur du système d'exploitation de s'exécuter soit dans l'espace utilisateur, soit dans l'espace noyau. Cela leur a permis de se développer dans l'espace utilisateur et de bénéficier de tous les avantages de l'idée originale de Mach, puis de déplacer le serveur débogué dans l'espace noyau afin d'obtenir de meilleures performances. Plusieurs systèmes d'exploitation ont depuis été construits à l'aide de cette méthode, connue sous le nom de co-location , parmi lesquels Lites , MkLinux , OSF/1 et NeXTSTEP/OPENSTEP/macOS. Le micronoyau Chorus en a fait une caractéristique du système de base, permettant aux serveurs d'être élevés dans l'espace du noyau à l'aide de mécanismes intégrés.

Mach 4 a tenté de résoudre ces problèmes, cette fois avec un ensemble de mises à niveau plus radicales. En particulier, il a été constaté que le code du programme n'était généralement pas accessible en écriture, de sorte que les accès potentiels dus à la copie sur écriture étaient rares. Il était donc logique de ne pas mapper la mémoire entre les programmes pour IPC, mais plutôt de migrer le code du programme utilisé dans l'espace local du programme. Cela a conduit au concept de "navettes" et il semblait que les performances s'étaient améliorées, mais les développeurs ont continué avec le système dans un état semi-utilisable. Mach 4 a également introduit des primitives de colocalisation intégrées, ce qui en fait une partie du noyau lui-même.

Au milieu des années 1990, les travaux sur les systèmes à micronoyau étaient en grande partie stagnants, bien que le marché ait généralement cru que tous les systèmes d'exploitation modernes seraient basés sur des micronoyaux d'ici les années 1990. Les principales utilisations encore répandues du noyau Mach sont macOS d'Apple et son frère iOS, qui s'exécutent sur un noyau hybride Open Software Foundation Mach (OSFMK 7.3) fortement modifié appelé " XNU " également utilisé dans OSF/1 . Dans XNU, les systèmes de fichiers, les piles de mise en réseau et les fonctions de gestion des processus et de la mémoire sont implémentés dans le noyau ; et le système de fichiers, la mise en réseau et certaines fonctions de gestion de processus et de mémoire sont invoqués à partir du mode utilisateur via des appels système ordinaires plutôt que par la transmission de messages ; Les messages Mach de XNU sont utilisés pour la communication entre les processus en mode utilisateur et pour certaines requêtes du code en mode utilisateur vers le noyau et du noyau vers les serveurs en mode utilisateur.

Micronoyaux de deuxième génération

Une analyse plus poussée a démontré que le problème de performance de l'IPC n'était pas aussi évident qu'il n'y paraissait. Rappelons qu'un seul côté d'un appel système a pris 20 s sous BSD et 114 s sur Mach fonctionnant sur le même système. Sur les 114, 11 étaient dus au changement de contexte, identique à BSD. 18 autres ont été utilisés par la MMU pour mapper le message entre l'espace utilisateur et l'espace noyau. Cela représente seulement 29μs, plus long qu'un appel système traditionnel, mais pas de beaucoup.

Le reste, la majorité du problème réel, était dû au noyau effectuant des tâches telles que la vérification du message pour les droits d'accès au port. Bien qu'il semble que ce soit un problème de sécurité important, en fait, cela n'a de sens que dans un système de type UNIX. Par exemple, un système d'exploitation mono-utilisateur exécutant un téléphone portable ou un robot peut ne pas avoir besoin de ces fonctionnalités, et c'est exactement le genre de système où le système d'exploitation pick-and-chois de Mach serait le plus précieux. De même, Mach a causé des problèmes lorsque la mémoire a été déplacée par le système d'exploitation, une autre tâche qui n'a vraiment de sens que si le système a plus d'un espace d'adressage. DOS et les premiers Mac OS ont un seul grand espace d'adressage partagé par tous les programmes, donc sous ces systèmes, le mappage n'a apporté aucun avantage.

Ces réalisations ont conduit à une série de micronoyaux de deuxième génération , qui ont encore réduit la complexité du système et placé presque toutes les fonctionnalités dans l'espace utilisateur. Par exemple, le noyau L4 (version 2) ne comprend que sept appels système et utilise 12 ko de mémoire, tandis que Mach 3 comprend environ 140 fonctions et utilise environ 330 ko de mémoire. Les appels IPC sous L4 sur un 486DX-50 ne prennent que 5 s, plus rapide qu'un appel système UNIX sur le même système, et plus de 20 fois plus rapide que Mach. Bien sûr, cela ignore le fait que L4 ne gère pas les autorisations ou la sécurité ; mais en laissant cela aux programmes de l'espace utilisateur, ils peuvent sélectionner autant ou aussi peu de frais généraux qu'ils le souhaitent.

Les gains de performances potentiels de L4 sont tempérés par le fait que les applications de l'espace utilisateur devront souvent fournir de nombreuses fonctions anciennement prises en charge par le noyau. Afin de tester les performances de bout en bout, MkLinux en mode co-localisé a été comparé à un port L4 exécuté dans l'espace utilisateur. L4 a ajouté environ 5% à 10% de frais généraux, contre 29% pour Mach.

Logiciel basé sur Mach

Ce qui suit est une liste des noyaux de système d'exploitation dérivés de Mach et des systèmes d'exploitation avec des noyaux dérivés de Mach :

Voir également

Les références

Liens externes