> moi je peux implémenter et lancer mon propre scheduler, qui répond à mes besoins, pour scheduler mes process, sans avoir à passer par le root, et encore moins à rebooter la machine.
J'ai bien compris ce gain "théorique". J'ai simplement constaté que pour les cas pratiques que tu indiques, les solutions "pratiques" sont implémentables sous Linux.
> Pas suffisante, même avec preempt
Preempt il ne sert à rien actuellement. D'ailleur je ne l'ai jamais utilisé :-)
> L'idée là c'est que même si tu as 30 process qui chacun veulent 100% du CPU, donner 1% garanti à intervalles réguliers (et c'est là la clef) à un processus n'est pas du tout impossible, et ne constitue pas un réel privilège pour le xmms.
Tu parle encore de latence. Il n'y a pas de difficulté majeur pour faire tourner un process qui utilise 1 % de cpu avec une charge à 30.
Pour xmms, le vrai problème n'est pas le noyau mais l'intéraction avec X11.
> qu'en même temps j'embête le serveur X par exemple, xmms saute un peu
Le problème c'est X11. X11 traite des donnés puis s'occupe des données envoyés par xmms. X11 traite les données de façon séquenciel.
J'ai la change d'avoir une carte graphique mga et j'ai installé le driver mga_vid. Avec ce driver (et mplayer), j'affiche des videos sans occuper X11 (l'affichage est toujours fait sous X11, c'est une sorte d'overlay). Si une vidéo bouffe en gros 20 % du cpu, je peux monter à 4 ou 5 de charge sans le moindre accro. Si j'écoute un ogg/vorbis avec un programme qui n'intéragit pas avec X11 je peux monter à une charge de 20 ou 30 sans le moindre accro.
Les deux gros points durs sous Linux sont :
- l'intéraction avec X11 lorsque plusieurs applis envoient des données à X11.
- les pages qui passent en swap alors qu'elles vont être utilisées dans la milli-seconde qui suit.
Pour les pages qui passent en swap, Linux propose déjà une solution (à déployer mais je ne suis pas convaincu que beaucoup d'appli le fasse car ce n'est pas très critique).
Pour X11, je ne suis pas convaincu que Hurd puisse améliorer la situation.
Exemple, avant d'avoir la carte mga et le driver mga_vid, je passais par l'extension XV de X11. J'avais beau mettre mplayer et/ou X11 en temps réel, il y avait toujours des accro :
- X11 reçoit une requête d'un programme lambda, la traite, ça prend 100 ms.
- mplayer prends la main, mais déjà 100 ms sont passés et t'as perdu au moins une image
Tu peux activer mplayer avant que X11 finisse la requête du programme lambda, ça ne change rien. L'affichage de mplayer sera fait lorsque la requête du programme lambda sera terminée. A moins de changer l'architecture d'X11, on ne peut échapper à ce problème.
> Si si, totalement. Linux dit "la licence vous permet de changer le scheduler, la VM
Ce n'est pas comme ça que j'entendai les choses. J'ai pris le point de vu de utilisateur. L'utilisateur a plus de posibilité/liberté avec Linux qu'avec Hurd actuellement.
[^] # Re: Mouai
Posté par fabb . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à -3.
J'ai bien compris ce gain "théorique". J'ai simplement constaté que pour les cas pratiques que tu indiques, les solutions "pratiques" sont implémentables sous Linux.
> Pas suffisante, même avec preempt
Preempt il ne sert à rien actuellement. D'ailleur je ne l'ai jamais utilisé :-)
> L'idée là c'est que même si tu as 30 process qui chacun veulent 100% du CPU, donner 1% garanti à intervalles réguliers (et c'est là la clef) à un processus n'est pas du tout impossible, et ne constitue pas un réel privilège pour le xmms.
Tu parle encore de latence. Il n'y a pas de difficulté majeur pour faire tourner un process qui utilise 1 % de cpu avec une charge à 30.
Pour xmms, le vrai problème n'est pas le noyau mais l'intéraction avec X11.
> qu'en même temps j'embête le serveur X par exemple, xmms saute un peu
Le problème c'est X11. X11 traite des donnés puis s'occupe des données envoyés par xmms. X11 traite les données de façon séquenciel.
J'ai la change d'avoir une carte graphique mga et j'ai installé le driver mga_vid. Avec ce driver (et mplayer), j'affiche des videos sans occuper X11 (l'affichage est toujours fait sous X11, c'est une sorte d'overlay). Si une vidéo bouffe en gros 20 % du cpu, je peux monter à 4 ou 5 de charge sans le moindre accro. Si j'écoute un ogg/vorbis avec un programme qui n'intéragit pas avec X11 je peux monter à une charge de 20 ou 30 sans le moindre accro.
Les deux gros points durs sous Linux sont :
- l'intéraction avec X11 lorsque plusieurs applis envoient des données à X11.
- les pages qui passent en swap alors qu'elles vont être utilisées dans la milli-seconde qui suit.
Pour les pages qui passent en swap, Linux propose déjà une solution (à déployer mais je ne suis pas convaincu que beaucoup d'appli le fasse car ce n'est pas très critique).
Pour X11, je ne suis pas convaincu que Hurd puisse améliorer la situation.
Exemple, avant d'avoir la carte mga et le driver mga_vid, je passais par l'extension XV de X11. J'avais beau mettre mplayer et/ou X11 en temps réel, il y avait toujours des accro :
- X11 reçoit une requête d'un programme lambda, la traite, ça prend 100 ms.
- mplayer prends la main, mais déjà 100 ms sont passés et t'as perdu au moins une image
Tu peux activer mplayer avant que X11 finisse la requête du programme lambda, ça ne change rien. L'affichage de mplayer sera fait lorsque la requête du programme lambda sera terminée. A moins de changer l'architecture d'X11, on ne peut échapper à ce problème.
> Si si, totalement. Linux dit "la licence vous permet de changer le scheduler, la VM
Ce n'est pas comme ça que j'entendai les choses. J'ai pris le point de vu de utilisateur. L'utilisateur a plus de posibilité/liberté avec Linux qu'avec Hurd actuellement.