Je réponds extrêmement rapidement à ça, parce que j'avoue être lassé de répondre à chaque fois la même chose - et à chaque fois de ne pas avoir de réponse.
Quant à la gestion de la mémoire, je n'imagine pas que quelqu'un avec une grande d'expérience de la programmation puisse penser que ça ne sert à rien. D'abord, pour ta curiosité : en pratique, il y a la bibliothèque libhurd-mm qui est automatiquement injectée dans l'espace d'adressage de ton application. De la même façon que dans beaucoup de systèmes une bibliothèque de compatibilité est injectée au démarrage. Pour changer de gestionnaire, il suffit en effet de fournir sa propre implémentation ou de lier avec une implémentation toute faite. Transparent pour les applications traditionnelles, et très simple pour les applications spécialisées. Je pense que Marcus a donné un excellent exemple de ce qu'une gestion des ressources décentralisée et contractualisée peut permettre (son + gravure).
Premier exemple plus important sur l'auto-pagination : les applications multimédia. Pour les applications multimédia assez spécifiques - mais grandement utilisées, j'en utilise moi-même -, les systèmes conventionnels sont très mal adaptés : en particulier, la gestion du swap amène à des catastrophes telle l'interruption d'un stream, ce qui va casser tout ton montage ou tout ton calcul. Pour ça, beaucoup utilisent des systèmes "vertically structured", ce qui se rapproche grandement des exo-noyaux (sauf qu'en général les premiers sont dans un seul espace d'adressage, et que ça n'est pas toujours le cas des seconds). C'est par exemple le cas de Nemesis. Je t'invite à lire le papier qui présente ce système et sa raison d'être. Si tu as le temps, travaille également le papier de thèse sur son implémentation : tout ce qui lui manque, c'est le fait qu'on le laisse tranquille pour gérer sa mémoire, et si possible, son temps CPU. C'est d'ailleurs la principale motivation des exo-noyaux : laisser les applications faire ce qu'elles veulent dans leur coin. La gestion de la mémoire décentralisée, c'est reprendre l'approche "exo-noyau" pour un point simple, qu'on sait marcher sans compromettre la sécurité le moins du monde. Et ça permet une scalabilité (oooh que c'est joli !) que Linux n'a pas, et qu'il n'aura probablement jamais. Avoir un seul système pour toutes les utilisations (dans un certain rang : tout système qui a une MMU par exemple) devrait être notre but, parce que ça permet de démocratiser beaucoup de domaines, et parce que ça simplifie énormément d'avoir les mêmes outils, les mêmes interfaces qu'on soit en train de faire du montage ou en train de jouer ou en train de faire de l'IRC.
Pour un autre exemple : on sait très bien qu'un SGDB, ça n'est qu'un énorme cache. C'est à dire qu'il a besoin d'une quantité de temps CPU relativement importante à des moments très précis, mais que dans la majorité du cas, il peut facilement donner du temps CPU pour gagner du temps. L'auto-pagination s'accompagne forcément d'un mécanisme de négociation des ressources. C'est à dire que plutôt que malloc() aille taper dans la mémoire du système jusqu'à ce que les quotas soient épuisés ou que simplement il n'y ait plus de mémoire virtuelle (et là, OOM killer!), quand on a plus assez de mémoire physique pour son utilisation, on va essayer d'en négocier avec un gestionnaire de ressources. Ce gestionnaire de ressources connaît ce qui est disponible, ce qui est rare, ce qui ne l'est pas. Il distribue aussi bien de la mémoire physique que du temps CPU. Il va de soi que notre SGDB va donc immédiatement échanger son temps CPU contre sa mémoire, et tenter l'opération inverse quand il en a besoin - ou alors se réserver juste un quota de temps CPU suffisant aux opérations classiques, dont il a relativement facilement connaissance. Un tel principe de contrat a été implémenté et testé en utilisant comme base le modèle du marché (chaque tâche dispose de X EUR au démarrage avec lesquels elle achète tant de mémoire, tant de temps CPU, ... ; avec le temps, il y a inflation ou déflation pour chacune des ressources ; ainsi, les applications pourront racheter de la mémoire contre peu de temps CPU quand elle sera peu chère (beaucoup de mémoire disponible), et beaucoup dans le cas inverse) : les améliorations sur un SGDBR étaient d'environ 40, 45%. Et je pense que personne qui s'est déjà penché sur un SGDBR ne contestera les chiffres : ils reflètent très bien la réalité de ces applications.
[^] # Re: Mouai
Posté par Manuel Menal . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 10.
PieD posait la même question sur : http://linuxfr.org/comments/532262.html#532262(...)
patrick_g posait la même question sur : http://linuxfr.org/comments/517501.html#517501(...)
des liens vers des commentaires plus vieux : http://linuxfr.org/comments/309640.html#309640(...)
Quant à la gestion de la mémoire, je n'imagine pas que quelqu'un avec une grande d'expérience de la programmation puisse penser que ça ne sert à rien. D'abord, pour ta curiosité : en pratique, il y a la bibliothèque libhurd-mm qui est automatiquement injectée dans l'espace d'adressage de ton application. De la même façon que dans beaucoup de systèmes une bibliothèque de compatibilité est injectée au démarrage. Pour changer de gestionnaire, il suffit en effet de fournir sa propre implémentation ou de lier avec une implémentation toute faite. Transparent pour les applications traditionnelles, et très simple pour les applications spécialisées. Je pense que Marcus a donné un excellent exemple de ce qu'une gestion des ressources décentralisée et contractualisée peut permettre (son + gravure).
Premier exemple plus important sur l'auto-pagination : les applications multimédia. Pour les applications multimédia assez spécifiques - mais grandement utilisées, j'en utilise moi-même -, les systèmes conventionnels sont très mal adaptés : en particulier, la gestion du swap amène à des catastrophes telle l'interruption d'un stream, ce qui va casser tout ton montage ou tout ton calcul. Pour ça, beaucoup utilisent des systèmes "vertically structured", ce qui se rapproche grandement des exo-noyaux (sauf qu'en général les premiers sont dans un seul espace d'adressage, et que ça n'est pas toujours le cas des seconds). C'est par exemple le cas de Nemesis. Je t'invite à lire le papier qui présente ce système et sa raison d'être. Si tu as le temps, travaille également le papier de thèse sur son implémentation : tout ce qui lui manque, c'est le fait qu'on le laisse tranquille pour gérer sa mémoire, et si possible, son temps CPU. C'est d'ailleurs la principale motivation des exo-noyaux : laisser les applications faire ce qu'elles veulent dans leur coin. La gestion de la mémoire décentralisée, c'est reprendre l'approche "exo-noyau" pour un point simple, qu'on sait marcher sans compromettre la sécurité le moins du monde. Et ça permet une scalabilité (oooh que c'est joli !) que Linux n'a pas, et qu'il n'aura probablement jamais. Avoir un seul système pour toutes les utilisations (dans un certain rang : tout système qui a une MMU par exemple) devrait être notre but, parce que ça permet de démocratiser beaucoup de domaines, et parce que ça simplifie énormément d'avoir les mêmes outils, les mêmes interfaces qu'on soit en train de faire du montage ou en train de jouer ou en train de faire de l'IRC.
Pour un autre exemple : on sait très bien qu'un SGDB, ça n'est qu'un énorme cache. C'est à dire qu'il a besoin d'une quantité de temps CPU relativement importante à des moments très précis, mais que dans la majorité du cas, il peut facilement donner du temps CPU pour gagner du temps. L'auto-pagination s'accompagne forcément d'un mécanisme de négociation des ressources. C'est à dire que plutôt que malloc() aille taper dans la mémoire du système jusqu'à ce que les quotas soient épuisés ou que simplement il n'y ait plus de mémoire virtuelle (et là, OOM killer!), quand on a plus assez de mémoire physique pour son utilisation, on va essayer d'en négocier avec un gestionnaire de ressources. Ce gestionnaire de ressources connaît ce qui est disponible, ce qui est rare, ce qui ne l'est pas. Il distribue aussi bien de la mémoire physique que du temps CPU. Il va de soi que notre SGDB va donc immédiatement échanger son temps CPU contre sa mémoire, et tenter l'opération inverse quand il en a besoin - ou alors se réserver juste un quota de temps CPU suffisant aux opérations classiques, dont il a relativement facilement connaissance. Un tel principe de contrat a été implémenté et testé en utilisant comme base le modèle du marché (chaque tâche dispose de X EUR au démarrage avec lesquels elle achète tant de mémoire, tant de temps CPU, ... ; avec le temps, il y a inflation ou déflation pour chacune des ressources ; ainsi, les applications pourront racheter de la mémoire contre peu de temps CPU quand elle sera peu chère (beaucoup de mémoire disponible), et beaucoup dans le cas inverse) : les améliorations sur un SGDBR étaient d'environ 40, 45%. Et je pense que personne qui s'est déjà penché sur un SGDBR ne contestera les chiffres : ils reflètent très bien la réalité de ces applications.
That's all, folks.