Pour ce qui est du giant lock,(appelé MPLock dans BSD si je me souviens bien), je ne sais pas, par contre il y a bien un point où ils ne sont pas novateurs par rapport à DragonFlyBSD dans ce paragraphe, c'est les unmapped buffers. DragonFly a introduit xio (désolé, pas de page de manuel, oui c'est assez triste) il y a 9ans. Il s'agit d'une implémentation de buffers non mappés.
Je vais essayer de résumer la situation telle que je la comprends, une partie des informations est peut être erronée, mais il me semble que le problème n'est pas le Giant Lock.
Un noyau unix présente aux applications une abstraction du matériel, et permet aux applications de partager celui ci. Les buffers jouent une place importantes dans cette tâche, car ils permettent de gérer des données d'entrée/sortie. Ils sont notament présents dans la couche VFS (systèmes de fichier) ou dans la pile réseau. L'interface couramment utilisée sous BSD s'appelle uio, elle date des temps anciens d'unix qui échappent à mes maigres talents d’archéologue. Hormis les détails d'implementation parce que ça stoque plus d'infos qu'un simple buffer, il s'agit de buffers classiques, qu'on peut résumer à un espace de mémoire et la taille du buffer. Si on veut allouer un nouveau buffer simple, il faut allouer de la mémoire virtuelle sur le tas, soit dans celle du noyau, soit dans le tas processus utilisateur.
Pour allouer des buffers sur le tas, il faut créer un mapping mémoire et reserver un espace contigu dans la mémoire virtuelle. Cette opération modifie la table des pages. Les noyaux BSD, (comme linux) que l'espace mémoire du noyau ne soit pas un espace distinct : il s'agit juste d'une zone mémoire mappée dans la "hight memory", c'est à dire le haut de l'espace d'addressage virtuel de chaque processus. C'est à dire que tout les processus en cours d'execution partagent ce mapping. S'il on crée un buffer, on doit donc informer tout les cpu que le mapping de cette zone à changé. Cela implique une synchronisation par Inter process interupt du TLB pour invalider l'ancien mapping. Il s'agit donc d'un point de contention sur les systèmes SMP.
Les buffers non mappés répondent à ce problème. Au lieu de mapper de la mémoire physique dans l'espace d'addressage, le buffer est une liste de page mémoire physique telle que représentées par le système de gestion de la mémoire virtuelle. Quand on veut écrire ou lire le buffer, on peut modifier directement et une à une ces pages mémoire physique. Bien évidement, c'est moins intuitif qu'un simple memcpy d'un block contigu de mémoire, mais en fournissant une api intuitive, le gain est substantiel. En effet, pour créer un buffer, il suffit desormais de trouver assez de page mémoire physique disponibles, et de les verouiller pour informer le système de gestion de la mémoire qu'elles sont utilisées. Il y a bien sûr là encore des verrous à traiter, mais avec un système de verrou à grain fin dans la gestion de la mémoire, les collisions sont beaucoup plus rare, il n'y a plus de synchronisation de tout les cpu à chaque fois. Ce gain peut être très important, il semble que les premières utilisations de xio sous dragonfly étaient pour un système de passage de message pour applications en espace utilisateur, et les archives de l'époque affirme que le gain était de 20%.
[^] # Re: Encore un Giant Lock ?
Posté par Enj0lras . En réponse à la dépêche FreeBSD 9.2 est là. Évalué à 10.
Pour ce qui est du giant lock,(appelé MPLock dans BSD si je me souviens bien), je ne sais pas, par contre il y a bien un point où ils ne sont pas novateurs par rapport à DragonFlyBSD dans ce paragraphe, c'est les unmapped buffers. DragonFly a introduit xio (désolé, pas de page de manuel, oui c'est assez triste) il y a 9ans. Il s'agit d'une implémentation de buffers non mappés.
Je vais essayer de résumer la situation telle que je la comprends, une partie des informations est peut être erronée, mais il me semble que le problème n'est pas le Giant Lock.
Un noyau unix présente aux applications une abstraction du matériel, et permet aux applications de partager celui ci. Les buffers jouent une place importantes dans cette tâche, car ils permettent de gérer des données d'entrée/sortie. Ils sont notament présents dans la couche VFS (systèmes de fichier) ou dans la pile réseau. L'interface couramment utilisée sous BSD s'appelle uio, elle date des temps anciens d'unix qui échappent à mes maigres talents d’archéologue. Hormis les détails d'implementation parce que ça stoque plus d'infos qu'un simple buffer, il s'agit de buffers classiques, qu'on peut résumer à un espace de mémoire et la taille du buffer. Si on veut allouer un nouveau buffer simple, il faut allouer de la mémoire virtuelle sur le tas, soit dans celle du noyau, soit dans le tas processus utilisateur.
Pour allouer des buffers sur le tas, il faut créer un mapping mémoire et reserver un espace contigu dans la mémoire virtuelle. Cette opération modifie la table des pages. Les noyaux BSD, (comme linux) que l'espace mémoire du noyau ne soit pas un espace distinct : il s'agit juste d'une zone mémoire mappée dans la "hight memory", c'est à dire le haut de l'espace d'addressage virtuel de chaque processus. C'est à dire que tout les processus en cours d'execution partagent ce mapping. S'il on crée un buffer, on doit donc informer tout les cpu que le mapping de cette zone à changé. Cela implique une synchronisation par Inter process interupt du TLB pour invalider l'ancien mapping. Il s'agit donc d'un point de contention sur les systèmes SMP.
Les buffers non mappés répondent à ce problème. Au lieu de mapper de la mémoire physique dans l'espace d'addressage, le buffer est une liste de page mémoire physique telle que représentées par le système de gestion de la mémoire virtuelle. Quand on veut écrire ou lire le buffer, on peut modifier directement et une à une ces pages mémoire physique. Bien évidement, c'est moins intuitif qu'un simple memcpy d'un block contigu de mémoire, mais en fournissant une api intuitive, le gain est substantiel. En effet, pour créer un buffer, il suffit desormais de trouver assez de page mémoire physique disponibles, et de les verouiller pour informer le système de gestion de la mémoire qu'elles sont utilisées. Il y a bien sûr là encore des verrous à traiter, mais avec un système de verrou à grain fin dans la gestion de la mémoire, les collisions sont beaucoup plus rare, il n'y a plus de synchronisation de tout les cpu à chaque fois. Ce gain peut être très important, il semble que les premières utilisations de xio sous dragonfly étaient pour un système de passage de message pour applications en espace utilisateur, et les archives de l'époque affirme que le gain était de 20%.