NB: Je ne répondrai pas au premier commentaire que je trouve effectivement très con. Il ne faut pas confondre non plus mauvaise foi et difficultés d'argumentation claire et d'expression précise. Kilobug est de bonne fois: sinon, il ne se documenterait pas sur G++, les subtilités du C++, pour son boulot, et se contenterait de faire de la merde en disant « de toutes façons, c'est pas de ma faute, c'est du C++ ».
Quant au cours sur le TLB flush etc. (qui n'en était pas un, c'était extrêmement bref et récapiulatif), c'était simplement pour remettre les choses au clair, avec toi et les autres lecteurs ici. Et bien s'assurer qu'on parle de la même chose: tu emploies parfois des termes assez bizarres, et j'avoue que j'ai parfois été tenté d'aller chercher le de-yoda-ifier.
J'aime d'ailleurs cet article car il indique explicitement que la technique en question peut être portée sous Linux monolithique et permet d'avoir les mêmes performances. Comme par hasard, kilobug et toi ne mentionnez pas ce fait. Mauvaise foi ?
Non. C'est d'ailleurs assez étrange, parce que nous en parlions justement y'a pas plus d'une heure (devant une pizza :-p) avec Kilobug, et nous ne savions pourquoi l'astuce du 2^52 sur PPC n'était pas utilisée par Linux sur cette architecture, car elle est très simple à réaliser. Mais, je ne pensais pas, et je ne pense toujours pas, que ça ait eu un intérêt dans l'optique de notre conversation et pour ce que je voulais montrer.
Effectivement les noyaux monolithiques pourraient l'utiliser, mais ça n'empêche que les systèmes à base de micro-noyaux peuvent ne pas être moins performant, notamment grâce à cette technique. Attention à ne pas rentrer dans la simplification schématique: 1) les systèmes µk-based sont moins rapides avant 2) on améliore les performances des deux => les systèmes µk-based sont toujours moins rapides comparativement. Si par exemple les systèmes µk-based étaient simplement plus lents à cause des cont-sw, et qu'on supprimait les cont-sw, ça mettrait les deux systèmes sur un pied d'égalité a priori. Pas plus.
Quelques explications sur mon délire de noyau. Quand je parle de passer en mode noyau, je veux bien sûr parler de changement de privilège. Quand j'ai dit "dans le noyau", je voulais dire un accès à un des services externes au noyau (dans le cadre des µ-noyaux). Oui, je sais, ça peut paraître délirant, mais bon, je ne suis pas toujours très clair.
Je ne sais pas si c'est la fatigue ou la guinness, mais je ne comprends toujours pas mieux ce que tu veux dire, et tu as fait lamentablement segfaulter mon de-yoda-ifier.
Enfin, tu réponds à des choses qui ne sont pas de moi (genre bench neutre)
Effectivement, je n'aime pas faire de multiples commentaires juste pour le plaisir, je préfère tout grouper. Peut-être à tort, puisque ça a l'air d'en effrayer certains. Il est vrai que mon style n'est de loin pas des meilleurs.
sans expliquer pourquoi il y aurait moins de lock dans un système à µ-noyaux que dans un système monolithique.
Uh? C'est quand même un peu évident. Plus tu as une grosse application avec plein de trucs qui s'effectuent en même temps, s'agissant en plus d'un noyau avec des interrupt handlers, des possibilités d'être reveillé d'un peu partout, et tout ça, plus tu vas avoir besoin de locks, et de complications pour éviter que toutes les pièces se marchent dessus. Tous ces locks ne sont pas justifiés lorsqu'il s'agit de tâches différentes. (bien sûr, il y'a toujours besoin de locks, sur des container et autres, mais ça n'a rien à voir, et ce ne sont pas des big global locks manipulés plus que fréquemment)
Pour les longs commentaires, euh, je les tape dans mon galeon, ou dans mon emacs puis je les copie dans mon galeon. GNU Emacs + Galeon, le couple gagnant ! ;P
[^] # 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.
Quant au cours sur le TLB flush etc. (qui n'en était pas un, c'était extrêmement bref et récapiulatif), c'était simplement pour remettre les choses au clair, avec toi et les autres lecteurs ici. Et bien s'assurer qu'on parle de la même chose: tu emploies parfois des termes assez bizarres, et j'avoue que j'ai parfois été tenté d'aller chercher le de-yoda-ifier.
J'aime d'ailleurs cet article car il indique explicitement que la technique en question peut être portée sous Linux monolithique et permet d'avoir les mêmes performances. Comme par hasard, kilobug et toi ne mentionnez pas ce fait. Mauvaise foi ?
Non. C'est d'ailleurs assez étrange, parce que nous en parlions justement y'a pas plus d'une heure (devant une pizza :-p) avec Kilobug, et nous ne savions pourquoi l'astuce du 2^52 sur PPC n'était pas utilisée par Linux sur cette architecture, car elle est très simple à réaliser. Mais, je ne pensais pas, et je ne pense toujours pas, que ça ait eu un intérêt dans l'optique de notre conversation et pour ce que je voulais montrer.
Effectivement les noyaux monolithiques pourraient l'utiliser, mais ça n'empêche que les systèmes à base de micro-noyaux peuvent ne pas être moins performant, notamment grâce à cette technique. Attention à ne pas rentrer dans la simplification schématique: 1) les systèmes µk-based sont moins rapides avant 2) on améliore les performances des deux => les systèmes µk-based sont toujours moins rapides comparativement. Si par exemple les systèmes µk-based étaient simplement plus lents à cause des cont-sw, et qu'on supprimait les cont-sw, ça mettrait les deux systèmes sur un pied d'égalité a priori. Pas plus.
Quelques explications sur mon délire de noyau. Quand je parle de passer en mode noyau, je veux bien sûr parler de changement de privilège. Quand j'ai dit "dans le noyau", je voulais dire un accès à un des services externes au noyau (dans le cadre des µ-noyaux). Oui, je sais, ça peut paraître délirant, mais bon, je ne suis pas toujours très clair.
Je ne sais pas si c'est la fatigue ou la guinness, mais je ne comprends toujours pas mieux ce que tu veux dire, et tu as fait lamentablement segfaulter mon de-yoda-ifier.
Enfin, tu réponds à des choses qui ne sont pas de moi (genre bench neutre)
Effectivement, je n'aime pas faire de multiples commentaires juste pour le plaisir, je préfère tout grouper. Peut-être à tort, puisque ça a l'air d'en effrayer certains. Il est vrai que mon style n'est de loin pas des meilleurs.
sans expliquer pourquoi il y aurait moins de lock dans un système à µ-noyaux que dans un système monolithique.
Uh? C'est quand même un peu évident. Plus tu as une grosse application avec plein de trucs qui s'effectuent en même temps, s'agissant en plus d'un noyau avec des interrupt handlers, des possibilités d'être reveillé d'un peu partout, et tout ça, plus tu vas avoir besoin de locks, et de complications pour éviter que toutes les pièces se marchent dessus. Tous ces locks ne sont pas justifiés lorsqu'il s'agit de tâches différentes. (bien sûr, il y'a toujours besoin de locks, sur des container et autres, mais ça n'a rien à voir, et ce ne sont pas des big global locks manipulés plus que fréquemment)
Pour les longs commentaires, euh, je les tape dans mon galeon, ou dans mon emacs puis je les copie dans mon galeon. GNU Emacs + Galeon, le couple gagnant ! ;P