> L'exemple le plus simple, c'est "quelle page swapper". Sans même aller chercher loin (les méchanismes de négociation de ressources), considérons juste un système qui au lieu de swapper une page en essayant de déterminer comme il peut (LRU, aging, ...) laquelle est la moins utilisée, va demander à l'application "désigne une page, et elle sera swappée".
OK, je comprend l'idée et elle est intéressante. Sans aucun doute elle mérite une étude approfondie.
Pour désigner les pages à swapper prioritairement, l'architecture de Linux ne me semble pas pénalisante pour le faire par rapport à Hurd. On peut déjà verrouiller des pages spécifiques en mémoire. Ici l'idée est de dire à l'OS : "s'il te plait, évites de swapper cette page".
> La question n'est pas là, la question un SGBDR qui va s'adapter, en troquant temps CPU (lookup) contre mémoire (cache) suivant les disponibilités des deux dans le système.
Là aussi j'ai compris l'intérêt :-)
> PostgreSQL utilise au moins l'un des deux (probablement mmap, peut-être les deux)
Oui et non. Mais l'architecture est faite pour que le SGDB (côté serveur) ne plante pas à cause d'un manque de mémoire. Au pire quelques transactions en cours sont abandonnées et les clients doivent refaire une connection. Tous les clients n'ont pas à se reconnecter. Seulement ceux dont le processus côté serveur a planté. L'architecture est différente de MySQL.
Mais je confirme que postmaster (le père des postgres côté serveur) n'a pas de mmap(), etc... Évidement qu'il utilise mmap() etc à son initialisation. Mais une fois qu'il est lancé il n'en fait plus.
> Pour le CPU, on peut par exemple concevoir un système où le temps CPU est réparti non entre processus, mais entre utilisateurs
> ...
> et où chaque utilisateur peut lui gérer comme il le souhaite le temps CPU pour ses propres applications
Dans la limite des quotas qu'on lui a donné. Sous Linux on peut toujours diminuer les privilèges, jamais les augmenter (sauf root).
> par exemple, son xmms sera prioritaire sur ses gcc et son firefox, de la manière qu'un processus RT l'est sous Linux, mais uniquement vis à vis du temps de l'utilisateur
Linux a trois classes d'ordonnanceur. Deux classe temps réel (très contraignantes et assez dangereuses à utiliser) avec plusieurs niveaux de priorité et une classe "sans privilège". Ici tu parles d'avoir une indirection supplémentaire (l'utilisateur) pour la classe "sans privilèges" et de partager le cpu en premier par utilisateur. J'aime l'idée et j'aimerai la voir réaliser (surtout dans le cas d'un type qui compile avec "make -j 20" :-) afin de ne pas emmerder les autres).
Mais Hurd ne me semble pas "nécessaire" pour ça comme il n'est pas nécessaire d'implémenter la vm côté utilisateur. Il ne semble pas plus difficile de le faire sous Linux que sous Hurd.
> le système "vend" à xmms un contrat valable 5 minutes pour avoir, de manière sûre, 10ms de temps CPU toutes les secondes. Le prix de cette "vente" dépendra de la charge de la machine. Au bout de 5 minutes, xmms devra renégocier le contrat.
Mouaif... Et si xmms n'a pas ce contrat ? Il arrête le lecture ou il continu est se disant que ça va peut-être passer ?
Je pense qu'il va prendre la seconde voie. Si finalement il n'a pas assez de cpu, il faut afficher une message. Donc tel que je le vois, ce n'est pas très intéressant.
De plus, pour xmms tu parles plus d'un problème de latence que d'un problème d'allocation de temps cpu. Pour la latence, Linux 2.6 est assez remarquable "natuellement". Pour mencoder, j'ai un problème de disponibilité de cpu et pas de latence (sauf forte charge ou pages swapées).
> Pour finir, une petite ouverture du sujet: c'est ça aussi, rendre la liberté aux utilisateurs (le but du projet GNU).
Mouaif... Qui donne le plus de liberté actuellement : Linux ou Hurd ?
Actuellement c'est Linux car il permet plus de chose. Que ça n'empêche pas Hurd de continuer avec cet objectif.
> C'est toute la différence entre "droit de chercher un emploi" (et sa variante "droit de travailler") et "droit d'obtenir un emploi" (et sa variante "droit au travail") par exemple, mais c'est un autre débat ;)
L'analogie n'est pas bonne.
Si Hurd c'est "droit d'avoir 1 Gflops par processus", ça ne marchera pas si la bécane n'est pas assez dimensionnée par rapport aux nombres de processus.
Linux c'est "vous avez droit à ce que je peux vous accorder ; inutile de faire des réclamation mais sachez que je fais de mon mieux".
[^] # Re: Mouai
Posté par fabb . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 4.
OK, je comprend l'idée et elle est intéressante. Sans aucun doute elle mérite une étude approfondie.
Pour désigner les pages à swapper prioritairement, l'architecture de Linux ne me semble pas pénalisante pour le faire par rapport à Hurd. On peut déjà verrouiller des pages spécifiques en mémoire. Ici l'idée est de dire à l'OS : "s'il te plait, évites de swapper cette page".
> La question n'est pas là, la question un SGBDR qui va s'adapter, en troquant temps CPU (lookup) contre mémoire (cache) suivant les disponibilités des deux dans le système.
Là aussi j'ai compris l'intérêt :-)
> PostgreSQL utilise au moins l'un des deux (probablement mmap, peut-être les deux)
Oui et non. Mais l'architecture est faite pour que le SGDB (côté serveur) ne plante pas à cause d'un manque de mémoire. Au pire quelques transactions en cours sont abandonnées et les clients doivent refaire une connection. Tous les clients n'ont pas à se reconnecter. Seulement ceux dont le processus côté serveur a planté. L'architecture est différente de MySQL.
Mais je confirme que postmaster (le père des postgres côté serveur) n'a pas de mmap(), etc... Évidement qu'il utilise mmap() etc à son initialisation. Mais une fois qu'il est lancé il n'en fait plus.
> Pour le CPU, on peut par exemple concevoir un système où le temps CPU est réparti non entre processus, mais entre utilisateurs
> ...
> et où chaque utilisateur peut lui gérer comme il le souhaite le temps CPU pour ses propres applications
Dans la limite des quotas qu'on lui a donné. Sous Linux on peut toujours diminuer les privilèges, jamais les augmenter (sauf root).
> par exemple, son xmms sera prioritaire sur ses gcc et son firefox, de la manière qu'un processus RT l'est sous Linux, mais uniquement vis à vis du temps de l'utilisateur
Linux a trois classes d'ordonnanceur. Deux classe temps réel (très contraignantes et assez dangereuses à utiliser) avec plusieurs niveaux de priorité et une classe "sans privilège". Ici tu parles d'avoir une indirection supplémentaire (l'utilisateur) pour la classe "sans privilèges" et de partager le cpu en premier par utilisateur. J'aime l'idée et j'aimerai la voir réaliser (surtout dans le cas d'un type qui compile avec "make -j 20" :-) afin de ne pas emmerder les autres).
Mais Hurd ne me semble pas "nécessaire" pour ça comme il n'est pas nécessaire d'implémenter la vm côté utilisateur. Il ne semble pas plus difficile de le faire sous Linux que sous Hurd.
> le système "vend" à xmms un contrat valable 5 minutes pour avoir, de manière sûre, 10ms de temps CPU toutes les secondes. Le prix de cette "vente" dépendra de la charge de la machine. Au bout de 5 minutes, xmms devra renégocier le contrat.
Mouaif... Et si xmms n'a pas ce contrat ? Il arrête le lecture ou il continu est se disant que ça va peut-être passer ?
Je pense qu'il va prendre la seconde voie. Si finalement il n'a pas assez de cpu, il faut afficher une message. Donc tel que je le vois, ce n'est pas très intéressant.
De plus, pour xmms tu parles plus d'un problème de latence que d'un problème d'allocation de temps cpu. Pour la latence, Linux 2.6 est assez remarquable "natuellement". Pour mencoder, j'ai un problème de disponibilité de cpu et pas de latence (sauf forte charge ou pages swapées).
> Pour finir, une petite ouverture du sujet: c'est ça aussi, rendre la liberté aux utilisateurs (le but du projet GNU).
Mouaif... Qui donne le plus de liberté actuellement : Linux ou Hurd ?
Actuellement c'est Linux car il permet plus de chose. Que ça n'empêche pas Hurd de continuer avec cet objectif.
> C'est toute la différence entre "droit de chercher un emploi" (et sa variante "droit de travailler") et "droit d'obtenir un emploi" (et sa variante "droit au travail") par exemple, mais c'est un autre débat ;)
L'analogie n'est pas bonne.
Si Hurd c'est "droit d'avoir 1 Gflops par processus", ça ne marchera pas si la bécane n'est pas assez dimensionnée par rapport aux nombres de processus.
Linux c'est "vous avez droit à ce que je peux vous accorder ; inutile de faire des réclamation mais sachez que je fais de mon mieux".
Merci pour ces excellentes précisions.