Et dire que j'ai cru un instant qu'il savait vraiment de quoi il parlait...
Il sait parfaitement de quoi il parle. Et ses goûts quant aux langages n'ont rien à voir avec ses connaissances techniques, qui concernant les micro-noyaux sont plus importantes que n'importe qui ici (pitet sauf moi, parce que c'est quand même moi qui l'ai convaincu ..). Les attaques personnelles de ce type sont plus que malsaines, elles m'écoeurent profondément.
J'ai relu tous les posts de Gaël ici (deux avis valent mieux qu'un), et je peux t'assurer qu'il n'est pas le seul qui aurait répondu comme ça. Peut-être effectivement est-ce dû à une mauvaise expression de ta part. Pour autant que je sache,
J'ai lu les docs L4 (avant de poster). Pour faire un IPC, on passe le thread en mode noyau (j'ai pas dit DANS LE NOYAU, j'ai dit en MODE NOYAU), exactement comme pour faire un appel système.
est un non-sens complet. On ne passe pas le thread en mode noyau. D'ailleurs, une définition correcte et assez précise du sens noyau, qui est la mienne (et ensuite celle de Kilobug), est qu'il consiste en tout ce qui tourne en mode « noyau ». On passe effectivement en mode noyau (instruction iret), mais tu changes pas les permissions d'un thread comme ça, hop. Il s'agit d'un CALL/SYSENTER (« inter-privilege-level far call », disent les docs Intel), puis d'un IRET/SYSEXIT. Effectivement, l'IPC entre tâches différentes se fait via un appel système avec L4 (et avec tout micro-noyau, en tous cas sur les architectures récentes et que je connais, avec MMU), il y'a donc le coût du changement de « privilege level » (relativement important sur un PIV, il faut l'avouer).
comment un IPC peut coûter moins cher qu'un appel système alors que l'IPC ajoute des instructions par rapport à l'appel système (on est d'accord, il y a très peu d'instructions en plus).
Si tu compares le nombre d'instructions, tu as en théorie raison. Cependant, ce que Kilobug t'a fait remarquer est que les mêmes instructions, les mêmes accès, faits dans des contextes différents n'a pas *du tout* le même poids. Le noyau est un énorme programme extrêmement complexe, où on doit lock'er de partout, etc. Le poids de ces locks est déjà un poids supplémentaire. L'empreinte sur le cache, étant donné que l'application est plus grosse, fait plus de choses, etc., est aussi considérablement plus importante. D'où encore pertes de performance. Or, il s'agit là d'un des facteurs *essentiels* vis-à-vis de ces dites performances. (Ceci dit, quand il s'agit du Hurd, on ne peut pas vraiment comparer, puisque le open() ne fait rien de comparable à ce que fait le open() de Linux.)
N'oublie pas qu'il s'agit de performances. On ne peut pas avoir une comparaison directe, fiable à 100%, manichéenne quand il s'agit de performances. Tel critère peut représenter une perte de performances, mais tel autre peut également, selon la façon dont s'est fait, selon les cas, etc., le compenser, voire plus. C'est pour ces raisons que Gaël a cité un certains nombres de choses qui peuvent te paraitre hors-sujet, mais qui pourtant ont un rôle prédominant quant aux performances. J'en profite d'ailleurs pour répondre à bknight, qui disait:
Le reste du débat micro noyau/monolithique m'apparaît de plus en plus comme une question de point de vue personnel. J'attends toujours un bench complètement neutre sur la chose.
La chose me paraît impossible. On ne peut pas faire des benchmarks sur des théories. Je peux te trouver des systèmes à base de micro-noyaux plus rapides que d'autres à base de noyaux monolithiques, et vice-versa. Il n'y a pas de bench parfait: même un bench du même code tournant sur un micro-noyau et sur un noyau monolithique serait absurde, parce que le code ne serait pas optimisé pour l'un ou l'autre (et d'ailleurs, par nature plutôt pour le second, puisqu'il s'agirait d'un serveur monolithique). C'est pour cela qu'il faut prendre les bench de L4Linux avec des pincettes. Et se souvenir que dans biens des cas MkLinux - « pendant » de L4Linux sur Mach - est bien souvent (tout le temps?) moins performant que le Hurd sur L4.
Les performances sont à traiter au cas par cas. Il semble logique, dans le cas d'un open(), qu'au final le coût soit à peu près le même: les pertes toutes relatives dues à l'IPC sont compensées par une moindre pollution des lignes de cache, etc. En revanche, dans le cas d'un write () où d'un appel plus complexe, l'utilisation de µk peut permettre d'utiliser des techniques plus performantes. Mais le µk en lui-même ne rendra pas les choses plus rapides, encore faut-il l'utiliser. C'est aussi pour ça que le Hurd est nouveau: certes les systèmes à base de micro-noyau ne sont pas nouveaux, mais aucun, sorti du domaine de la recherche, n'en tirait parti comme le Hurd, à ma connaissance, et encore moins comme il le fera quand le port sur L4 sera terminé.
Une petite remarque de forme. C'est gentil de toujours faire référence aux papiers sur L4, mais bon, je ne connais pas beaucoup de chercheurs qui crachent dans leur propre soupe.
Effectivement, cela est vrai. Mais il n'empêche que ce qu'il présente, ce sont avant tout des *faits*. Et à moins que tu me montres qu'ils sont faux, infondés, ou que sais-je, ce sont la base d'arguments valides. De même que je ne connais pas de papiers qui proposent des contre-arguments à L4, ou qui montrent que c'est faux, que c'est forcément plus lent avec L4. Le seul qui m'ait dit ça, c'est Rik (Van Riel), et bizarrement, il a toujours quelque chose de très urgent à faire dès qu'il s'agit de me montrer en quoi.
Mais qu'est-ce que tu racontes ? Comment fais tu un ipc sûr sans passer en mode noyau ?
Là, je voudrais nuancer légèrement. Tu ne peux pas faire d'IPC sûr sans passer par le mode noyau, effectivement, si on garde à l'esprit que IPC = « Inter Process Task ». En revanche, tu peux faire des RPCs locales, i.e., entre threads d'un même groupe, d'une même tâche, sans passer par le mode noyau. (et oui, c'est utile, je vous prie de se referrer au début et à l'ensemble de http://www.l4ka.org/publications/files/lazy-process-switching.ps(...) (oh! mon Dieu, encore une référence aux docs L4! Mais ce gars n'y connait rien! sauf que ce gars échange avec Horst Wenske (mais malheureusement pas avec le regretté Jochen Liedtke :-( ))). Ça s'appelle LIPC, et ça fait partie des services qu'un noyau et qu'un système d'exploitations peuvent fournir pour permettre d'avoir un ensemble plus rapide.
Euh, c'est une question piège ? Disons, un RPC ? Le problème, c'est que sauf erreur de ma part, ça fait un changement de contexte et que ça coute des ressources (par exemple tu dois avoir un risque de niquer le cache).
<tribune>Pas du tout, efface.</tribune> Cela fait un changement de contexte dans quelques cas très particuliers. Enfin, soyons clair. Cela fait un changement de contexte dans tous les cas: on change de tâche, on modifie deux/trois trucs. Mais c'est une hyperbole que dire que c'est peu coûteux. De plus, le cache primaire est indexé physiquement, donc cela ne coûte encore une fois que quelques cycles. Les coûts sont donc liés à, comme tu le dis, au « cache » (« niquer le cache », expression qui me plait décidément beaucoup). Plus exactement, au TLB. Liedtke décrit des mécanismes pour PowerPC et pour x86. L'idée pour x86 est assez simple: sur les 4GO d'espaces d'adressage, les tâches qui ne requièrent pas un espace d'adressage phénoménal (i.e., <500MB, si mes souvenirs sont bons, mais cela a pu changer et est peu ou pas décrit par Intel), donc la vaste majorité des tâches (en fait, toutes sauf 1 ou 2 sur la plupart des systèmes), n'ont pas accès aux 3GO d'address space normaux, mais seulement à une petite partie, de 500MB. Or il est tout à fait possible de multiplexer, de partager ces petits espaces d'adressages entre les gros, de 4GO. Dans la plupart des cas, un « changement de contexte » se fait entre deux tâches occupant des petits espaces d'adressage. Il n'y a donc pas de réel changement de page table, donc pas de TLB flush, donc pas un « réel » changement de contextes. En revanche, il est vrai que dans les cas où une petite tâche va faire une RPC à une tâche disposant d'un gros espace d'adressage n'étant pas celui en cours, ou encore dans le cas de communication entre « grosses » tâches, un TLB flush va être nécessité. Mais l'économie par rapport au context switch sur Linux, ou plein d'autres systèmes - Windows NT, pour autant que je sache - est monstrueuse. Pour PowerPC, c'est encore plus simple, et pour le coup il n'y a plus du tout de TLB flush, puisqu'il est très facile d'avoir un address space de 2^52 bytes, et donc d'« émuler » une TLB taggée sans ses inconvénients.
Tout ça pour dire que aujourd'hui je pense qu'aucun système à micro-noyau n'est aussi performant qu'un système "monolithique".
Ça ne veut pas dire grand chose, tu t'en rends compte ? GNU/Hurd est probablement plus rapide que certains systèmes d'exploitation basés sur des noyaux monolithiques. Qu'en revanche il n'existe pas de systèmes d'exploitation aussi versatile que GNU/Linux basé sur un micro-noyau qui soit aussi rapide que ce dernier, je te l'accorde. Mais encore une fois, ça ne constitue pas du tout une preuve. Il n'existe pas à ma connaissance de raisons pour lesquelles ça ne serait pas possible, et il existe même des raisons de penser qu'on pourrait faire un système d'exploitation à base de micro-noyau plus rapide. Si je n'en étais pas persuadé, je ne travaillerais pas sur le port du Hurd sur L4.
Pour finir, j'aimerais revenir sur le commentaire auquel je réponds directement. Je ne sais pas ce que tu essayais de prouver en rappelant les positions de Kilobug sur un tout autre sujet, à savoir le C vs. le C++. Je connais bien Kilobug, mieux que quiconque ici (et que la plupart ailleurs), et je suis d'ailleurs d'accord avec lui sur ce point: le C++ n'est pas un langage que j'aime, et je le trouve absolument dégueulasse. Est-ce que pour autant on doit m'enlever le droit de m'exprimer ? Est-ce que ça m'enlève tout crédit pour parler d'autre chose, et même de ça ? D'autant plus que Kilobug fait du C++ tous les jours (ach, 3j/sem maintenant), et que donc il ne parle pas sans savoir. Il est même probablement plus renseigné dessus que beaucoup de monde ici, puisqu'il lit énormément et est de bonne volonté à ce sujet. Bref, je trouve ces méthodes digne des plus grands boulets, des plus infâmes, que l'on peut malheureusement rencontrer sur DLFP. Plus que de casser la crédibilité de Kilobug, c'est la tienne que tu viens de casser à mes yeux et aux yeux de nombre d'autres.
Ceci dit, le débat purement technique sur les micro-noyaux m'intéresse, et je pense être pas trop mal renseigné sur le sujet. Donc, puisque cette news n'est plus depuis longtemps en page principale, je vous invite, tous, et en particulier toi et bknight (et puis jjb<, s'il veut :-), à continuer la discussion sur une ML, et même devant une guinness si vous habitez dans la région parisienne (oui, oui, un lait fraise pour kilobug :-).
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Manuel Menal . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Il sait parfaitement de quoi il parle. Et ses goûts quant aux langages n'ont rien à voir avec ses connaissances techniques, qui concernant les micro-noyaux sont plus importantes que n'importe qui ici (pitet sauf moi, parce que c'est quand même moi qui l'ai convaincu ..). Les attaques personnelles de ce type sont plus que malsaines, elles m'écoeurent profondément.
J'ai relu tous les posts de Gaël ici (deux avis valent mieux qu'un), et je peux t'assurer qu'il n'est pas le seul qui aurait répondu comme ça. Peut-être effectivement est-ce dû à une mauvaise expression de ta part. Pour autant que je sache,
J'ai lu les docs L4 (avant de poster). Pour faire un IPC, on passe le thread en mode noyau (j'ai pas dit DANS LE NOYAU, j'ai dit en MODE NOYAU), exactement comme pour faire un appel système.
est un non-sens complet. On ne passe pas le thread en mode noyau. D'ailleurs, une définition correcte et assez précise du sens noyau, qui est la mienne (et ensuite celle de Kilobug), est qu'il consiste en tout ce qui tourne en mode « noyau ». On passe effectivement en mode noyau (instruction iret), mais tu changes pas les permissions d'un thread comme ça, hop. Il s'agit d'un CALL/SYSENTER (« inter-privilege-level far call », disent les docs Intel), puis d'un IRET/SYSEXIT. Effectivement, l'IPC entre tâches différentes se fait via un appel système avec L4 (et avec tout micro-noyau, en tous cas sur les architectures récentes et que je connais, avec MMU), il y'a donc le coût du changement de « privilege level » (relativement important sur un PIV, il faut l'avouer).
comment un IPC peut coûter moins cher qu'un appel système alors que l'IPC ajoute des instructions par rapport à l'appel système (on est d'accord, il y a très peu d'instructions en plus).
Si tu compares le nombre d'instructions, tu as en théorie raison. Cependant, ce que Kilobug t'a fait remarquer est que les mêmes instructions, les mêmes accès, faits dans des contextes différents n'a pas *du tout* le même poids. Le noyau est un énorme programme extrêmement complexe, où on doit lock'er de partout, etc. Le poids de ces locks est déjà un poids supplémentaire. L'empreinte sur le cache, étant donné que l'application est plus grosse, fait plus de choses, etc., est aussi considérablement plus importante. D'où encore pertes de performance. Or, il s'agit là d'un des facteurs *essentiels* vis-à-vis de ces dites performances. (Ceci dit, quand il s'agit du Hurd, on ne peut pas vraiment comparer, puisque le open() ne fait rien de comparable à ce que fait le open() de Linux.)
N'oublie pas qu'il s'agit de performances. On ne peut pas avoir une comparaison directe, fiable à 100%, manichéenne quand il s'agit de performances. Tel critère peut représenter une perte de performances, mais tel autre peut également, selon la façon dont s'est fait, selon les cas, etc., le compenser, voire plus. C'est pour ces raisons que Gaël a cité un certains nombres de choses qui peuvent te paraitre hors-sujet, mais qui pourtant ont un rôle prédominant quant aux performances. J'en profite d'ailleurs pour répondre à bknight, qui disait:
Le reste du débat micro noyau/monolithique m'apparaît de plus en plus comme une question de point de vue personnel. J'attends toujours un bench complètement neutre sur la chose.
La chose me paraît impossible. On ne peut pas faire des benchmarks sur des théories. Je peux te trouver des systèmes à base de micro-noyaux plus rapides que d'autres à base de noyaux monolithiques, et vice-versa. Il n'y a pas de bench parfait: même un bench du même code tournant sur un micro-noyau et sur un noyau monolithique serait absurde, parce que le code ne serait pas optimisé pour l'un ou l'autre (et d'ailleurs, par nature plutôt pour le second, puisqu'il s'agirait d'un serveur monolithique). C'est pour cela qu'il faut prendre les bench de L4Linux avec des pincettes. Et se souvenir que dans biens des cas MkLinux - « pendant » de L4Linux sur Mach - est bien souvent (tout le temps?) moins performant que le Hurd sur L4.
Les performances sont à traiter au cas par cas. Il semble logique, dans le cas d'un open(), qu'au final le coût soit à peu près le même: les pertes toutes relatives dues à l'IPC sont compensées par une moindre pollution des lignes de cache, etc. En revanche, dans le cas d'un write () où d'un appel plus complexe, l'utilisation de µk peut permettre d'utiliser des techniques plus performantes. Mais le µk en lui-même ne rendra pas les choses plus rapides, encore faut-il l'utiliser. C'est aussi pour ça que le Hurd est nouveau: certes les systèmes à base de micro-noyau ne sont pas nouveaux, mais aucun, sorti du domaine de la recherche, n'en tirait parti comme le Hurd, à ma connaissance, et encore moins comme il le fera quand le port sur L4 sera terminé.
Une petite remarque de forme. C'est gentil de toujours faire référence aux papiers sur L4, mais bon, je ne connais pas beaucoup de chercheurs qui crachent dans leur propre soupe.
Effectivement, cela est vrai. Mais il n'empêche que ce qu'il présente, ce sont avant tout des *faits*. Et à moins que tu me montres qu'ils sont faux, infondés, ou que sais-je, ce sont la base d'arguments valides. De même que je ne connais pas de papiers qui proposent des contre-arguments à L4, ou qui montrent que c'est faux, que c'est forcément plus lent avec L4. Le seul qui m'ait dit ça, c'est Rik (Van Riel), et bizarrement, il a toujours quelque chose de très urgent à faire dès qu'il s'agit de me montrer en quoi.
Mais qu'est-ce que tu racontes ? Comment fais tu un ipc sûr sans passer en mode noyau ?
Là, je voudrais nuancer légèrement. Tu ne peux pas faire d'IPC sûr sans passer par le mode noyau, effectivement, si on garde à l'esprit que IPC = « Inter Process Task ». En revanche, tu peux faire des RPCs locales, i.e., entre threads d'un même groupe, d'une même tâche, sans passer par le mode noyau. (et oui, c'est utile, je vous prie de se referrer au début et à l'ensemble de http://www.l4ka.org/publications/files/lazy-process-switching.ps(...) (oh! mon Dieu, encore une référence aux docs L4! Mais ce gars n'y connait rien! sauf que ce gars échange avec Horst Wenske (mais malheureusement pas avec le regretté Jochen Liedtke :-( ))). Ça s'appelle LIPC, et ça fait partie des services qu'un noyau et qu'un système d'exploitations peuvent fournir pour permettre d'avoir un ensemble plus rapide.
Euh, c'est une question piège ? Disons, un RPC ? Le problème, c'est que sauf erreur de ma part, ça fait un changement de contexte et que ça coute des ressources (par exemple tu dois avoir un risque de niquer le cache).
<tribune>Pas du tout, efface.</tribune> Cela fait un changement de contexte dans quelques cas très particuliers. Enfin, soyons clair. Cela fait un changement de contexte dans tous les cas: on change de tâche, on modifie deux/trois trucs. Mais c'est une hyperbole que dire que c'est peu coûteux. De plus, le cache primaire est indexé physiquement, donc cela ne coûte encore une fois que quelques cycles. Les coûts sont donc liés à, comme tu le dis, au « cache » (« niquer le cache », expression qui me plait décidément beaucoup). Plus exactement, au TLB. Liedtke décrit des mécanismes pour PowerPC et pour x86. L'idée pour x86 est assez simple: sur les 4GO d'espaces d'adressage, les tâches qui ne requièrent pas un espace d'adressage phénoménal (i.e., <500MB, si mes souvenirs sont bons, mais cela a pu changer et est peu ou pas décrit par Intel), donc la vaste majorité des tâches (en fait, toutes sauf 1 ou 2 sur la plupart des systèmes), n'ont pas accès aux 3GO d'address space normaux, mais seulement à une petite partie, de 500MB. Or il est tout à fait possible de multiplexer, de partager ces petits espaces d'adressages entre les gros, de 4GO. Dans la plupart des cas, un « changement de contexte » se fait entre deux tâches occupant des petits espaces d'adressage. Il n'y a donc pas de réel changement de page table, donc pas de TLB flush, donc pas un « réel » changement de contextes. En revanche, il est vrai que dans les cas où une petite tâche va faire une RPC à une tâche disposant d'un gros espace d'adressage n'étant pas celui en cours, ou encore dans le cas de communication entre « grosses » tâches, un TLB flush va être nécessité. Mais l'économie par rapport au context switch sur Linux, ou plein d'autres systèmes - Windows NT, pour autant que je sache - est monstrueuse. Pour PowerPC, c'est encore plus simple, et pour le coup il n'y a plus du tout de TLB flush, puisqu'il est très facile d'avoir un address space de 2^52 bytes, et donc d'« émuler » une TLB taggée sans ses inconvénients.
Tout ça pour dire que aujourd'hui je pense qu'aucun système à micro-noyau n'est aussi performant qu'un système "monolithique".
Ça ne veut pas dire grand chose, tu t'en rends compte ? GNU/Hurd est probablement plus rapide que certains systèmes d'exploitation basés sur des noyaux monolithiques. Qu'en revanche il n'existe pas de systèmes d'exploitation aussi versatile que GNU/Linux basé sur un micro-noyau qui soit aussi rapide que ce dernier, je te l'accorde. Mais encore une fois, ça ne constitue pas du tout une preuve. Il n'existe pas à ma connaissance de raisons pour lesquelles ça ne serait pas possible, et il existe même des raisons de penser qu'on pourrait faire un système d'exploitation à base de micro-noyau plus rapide. Si je n'en étais pas persuadé, je ne travaillerais pas sur le port du Hurd sur L4.
Pour finir, j'aimerais revenir sur le commentaire auquel je réponds directement. Je ne sais pas ce que tu essayais de prouver en rappelant les positions de Kilobug sur un tout autre sujet, à savoir le C vs. le C++. Je connais bien Kilobug, mieux que quiconque ici (et que la plupart ailleurs), et je suis d'ailleurs d'accord avec lui sur ce point: le C++ n'est pas un langage que j'aime, et je le trouve absolument dégueulasse. Est-ce que pour autant on doit m'enlever le droit de m'exprimer ? Est-ce que ça m'enlève tout crédit pour parler d'autre chose, et même de ça ? D'autant plus que Kilobug fait du C++ tous les jours (ach, 3j/sem maintenant), et que donc il ne parle pas sans savoir. Il est même probablement plus renseigné dessus que beaucoup de monde ici, puisqu'il lit énormément et est de bonne volonté à ce sujet. Bref, je trouve ces méthodes digne des plus grands boulets, des plus infâmes, que l'on peut malheureusement rencontrer sur DLFP. Plus que de casser la crédibilité de Kilobug, c'est la tienne que tu viens de casser à mes yeux et aux yeux de nombre d'autres.
Ceci dit, le débat purement technique sur les micro-noyaux m'intéresse, et je pense être pas trop mal renseigné sur le sujet. Donc, puisque cette news n'est plus depuis longtemps en page principale, je vous invite, tous, et en particulier toi et bknight (et puis jjb<, s'il veut :-), à continuer la discussion sur une ML, et même devant une guinness si vous habitez dans la région parisienne (oui, oui, un lait fraise pour kilobug :-).