Feature freeze du noyau 2.5/2.6 prévu pour Halloween

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
21
juil.
2002
Noyau
Un gel des fonctionnalités du noyau 2.5 (futur 2.6) a été décidé pour Halloween. Après cette date, seuls des corrections de bugs ou des améliorations mineures seront acceptés dans ce qui deviendra le noyau 2.6.

Pour voir la liste des modifications majeures déjà effectuées, et celles qui sont prévues, suivez le lien sur kernelnewbies. Pour résumer: beaucoup de parties ont été réécrites (block io, ide, framebuffer, ...) et pas mal de patchs externes ont été intégrés ou le seront (preempt, ALSA, ACL, rmap, ...)

Aller plus loin

  • # Correction ...

    Posté par  . Évalué à 10.

    Y'a une erreur pour le mail sur les fonctionalités. Le mail dans la news est celui qui a servi pour une discussion puis Guillaume Boissiere a proposé la version finale qui est à l'adresse:

    http://www.uwsg.iu.edu/hypermail/linux/kernel/0207.2/0870.html(...)

    tous les détails à kerneltrap.org :

    http://kerneltrap.org/node.php?id=348(...)

  • # -rmap

    Posté par  . Évalué à 10.

    Je tiens à préciser qu'une version minimale de -rmap a été intégrée dans le noyau 2.5.27. -rmap est une nouvelle VM (Virtual Memory: gestion de la mémoire virtuelle, du swap, du cache disque, ...) créée par Rik Van Riel et qui utilise le principe du reverse mapping (au lieu d'avoir juste une liste de pages utilisées par chaque processus le noyau maintient aussi une liste des processus utilisant chacune des pages, ce qui lui permet de mieux "décider" quelle page garder et quelle page swapper).

    Le mail présentant le patch "Minimal -rmap" ainsi que les possibilités futures du reverse mapping est sur http://www.uwsg.iu.edu/hypermail/linux/kernel/0207.2/0265.html(...)

    PS: désolé, mais j'ai été mis au courant l'intégration de ce patch après avoir poster ma news

    • [^] # Re: -rmap

      Posté par  (site web personnel) . Évalué à -10.

      La VM de qui ?

      hop -1

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: -rmap

      Posté par  (site web personnel) . Évalué à -10.

      la VM de qui ?

      hop -1

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: -rmap

      Posté par  . Évalué à 10.

      > ce qui lui permet de mieux "décider"

      mieux par rapport a quoi ? l'actuel 2.4.18 ?
      le gain est il qualifiable et quantifiable ?
      Dans quelles circonstances ( machine tres chargee ou en utilisation courante ) ?

      • [^] # Re: -rmap

        Posté par  . Évalué à 10.

        > mieux par rapport a quoi ? l'actuel 2.4.18 ?

        Le patch inclu dans le noyau 2.5.26 n'utilise pas encore les possibilités du -rmap, ce n'est qu'un patch minimal qui implémente le reverse mapping.

        Le patch -rmap complet (qui lui ne s'applique que sur un noyau 2.4 et est inclus dans les noyaux -ac et -mjc) donne des résultats concrets, même s'ils sont discutés.

        > le gain est il qualifiable et quantifiable ?

        Il est très difficile de quantifié ce genre de gain, les benchs de VM sont très peu fiables, et les débats là-dessus assez houleux. Surtout que -rmap est encore en cours d'optimisation.

        Ce qui est sûr c'est que -rmap permet au moins de faire passer l'agorithme de remplacement de pages en O(mémoire physique) et non en O(mémoire virtuelle) comme c'est le cas actuellement (mémoire virtuelle incluant le swap, plusieurs fois les pages partagées, ...) donc si la machine est chargée le gain est appréciable.

        Un autre problème de la VM courante, liée à l'archi x86, est que le DMA nécessite des pages contigües situées au dessous de 16Mo de mémoire physique pour fonctionner, or obtenir ce genre de page sur une VM classique obligé à parcourir l'ensemble de l'espace d'addressage de tous les processus pour trouver les pages se trouvant dans la bonne zone, avec -rmap c'est instantanné, il suffit de regarder les pages intéressantes directement.

        • [^] # Re: -rmap

          Posté par  . Évalué à 2.

          Un autre problème de la VM courante, liée à l'archi x86, est que le DMA nécessite des pages contigües situées au dessous de 16Mo de mémoire physique pour fonctionner Il me semblait que la DMA limitée à 16 Mo ne concernait que les cartes ISA. L'exemple concret que j'ai est mon ancienne carte son SoundBlaster ISA, pour laquelle j'avais dû préciser un paramètre dans je ne sais plus quel fichier de configuration (modules.conf, ou un paramètre au boot ?), pour dire (au driver OSS je suppose) de n'allouer que de la mémoire en dessous de cette limite.

  • # Dept:

    Posté par  (site web personnel) . Évalué à -10.

    C'est pas "En attendant GNU/Le Hurd" ?!?

    -1

    • [^] # Re: Dept:

      Posté par  . Évalué à -2.

      Non.
      Enfin, j'aurais peut-être pu dire "En attendant le GNU Hurd".
      On a "GNU/Hurd" ou "GNU" qui désigne le système d'exploitation GNU complet, et "le Hurd" ou "le GNU Hurd" (ou "le Troupeau") qui désigne uniquement les serveurs et bibliothèques qui composent le Hurd, mais pas le reste (pas le micro-noyau, ni la libc, ni les outils GNU, ...)

      -1 HS

      • [^] # Re: Dept:

        Posté par  . Évalué à -10.

        kilobug, t'est mon idole :)

        -1 pour prosternation abusive

  • # Et les 2.4 ?

    Posté par  . Évalué à 10.

    Ca fait plusieurs mois maintenant qu'il n'y a pas eu de nouveau kernel dans la branche des 2.4 ... quelqu'un sait pourquoi ?

    • [^] # Re: Et les 2.4 ?

      Posté par  . Évalué à 10.

      C'est lié au changement de maintainer du kernel.
      Marcello Tosatti semble prendre beaucoup plus son temps pour assurer des releases stables.

      Il multiplie les release candidates (chose assez rare avant). Il en a sorti une il y a quelques jours pour 2.4.19, et sauf gros probleme c'est la dernière.

      La prochaine release est donc imminente...

      • [^] # Re: Et les 2.4 ?

        Posté par  (site web personnel) . Évalué à 10.

        Ca vient aussi du fait qu'avant le 2.4.16, la gestion de la VM était pas toujours très bonne et très changeante...

        D'où la fréquence elevée des versions...
        Et en plus le 2.4.x était jeune !

        Maintenant, on peut remarquer qu'il comporte beaucoup moins de problème...

        • [^] # Re: Et les 2.4 ?

          Posté par  . Évalué à 10.

          Honnêtement, la VM du noyau 2.4.18 est loin d'être terrible, -rmap (inclue dans les noyaux -ac et -mjc) est beaucoup plus fiable et performante (c'est en tout cas mon impression aussi bien à l'utilisation qu'à la lecture des ML)... Maintenant c'est vrai que changer de VM en plein milieu d'une branche stable (2.4.10) ça a multiplié le nombre de noyaux sortis rapidement pour corriger tout ça...

          Sinon, pour Marcelo, il prend son temps et c'est pas plus mal... on est au 2.4.19-rc3, le 2.4.19 ne devrait donc pas trop tarder.

          • [^] # Re: Et les 2.4 ?

            Posté par  . Évalué à 10.

            Si les releases sont moins fréquentes c'est surtout du au fait que théoriquement, dans le meilleur des mondes, une fois la release stable sortie, il n'y a plus de release à faire.

            Si il n'y avait pas eu de problème sur le 2.4.0, il n'y aurait pas eu de 2.4.1 et ainsi de suite. La série 2.4 comme se fut le cas pour la 2.2 et surement aussi pour la 2.6, sont des releases "stables" qui n'ont pas pour vocation de jouer à la course des nouvelles fonctionalitées, mais plutôt à la stabilitée.


            Il arrive de temps en temps que l'on rajoute une nouvelle fonctionalité en milieu d'une release stable car on estime qu'elle apporte suffisement de fonctionalité (ou rapidité) pour coût d'intégration faible (fonctionalité ultra-localisée).

            Je trouve pour ma part plutot rassurant que le 2.4.19 ne soit toujours pas sorti. Ca signifie que le kernel 2.4.18 que j'utilise n'est pas trop buggé.

  • # Vivement la 2.6

    Posté par  . Évalué à 10.

    Bon, c est peut etre une impression subjective, mais il me semble que le temps entre la 2.4 et la 2.6 est bien inferieur aux precedents changements majeurs de version (1.0->1.2 ; 1.2->2.0 ; 2.0->2.2 ; et 2.2->2.4)
    Est-ce du a une augmentation du nombre de developpeur, a un changement de version comportant moins de nouveaute que les precedants, ou tout simplement une erreur de ma part ...
    En tout cas une chose est sure, vivement la 2.6 vu les nouveautes qu elle integre, et je dois certainement pas etre le seul a l attendre ... :)

    • [^] # Re: Vivement la 2.6

      Posté par  . Évalué à 10.

      Pas tant que ça, le 2.4 date de janvier 2001, avec un feature freeze à Halloween, on aura pas de 2.6 avant 2003, ça fera un peu plus de deux ans entre le 2.4 et et le 2.6, ce qui est le rythme pour les précédentes versions aussi

      linux-2.0.1.tar.bz2 4626 KB 03.07.1996 00:00:00

      linux-2.2.0.tar.bz2 10345 KB 26.01.1999 00:00:00

      linux-2.4.0.tar.bz2 19325 KB 04.01.2001 00:00:00

    • [^] # Re: Vivement la 2.6

      Posté par  . Évalué à -9.

      petit papa noël
      quand tu descendra du ciel
      avec ton kernel pas buggé
      n'oublie pas mon petit soulier

      -1 pour tino rossi...

    • [^] # Re: Vivement la 2.6

      Posté par  . Évalué à 10.

      Impression plutôt dûe au fait que le 2.4 est devenu réellement stable assez tardivement, à mon avis (suite aux nombreux problèmes avec la VM entre autres). Le "vrai" 2.4.0 aurait plutot dû être aux alentours deu 2.4.13 ou 2.4.14 ...
      Enfin ne revenons pas trop sur cette histoire de VM, qui a été une belle foire d'empoigne, mais perso j'espère que cette nouvelle VM -rmap du 2.6 sera enfin à la hauteur du reste du noyau ;-))

      • [^] # Re: Vivement la 2.6

        Posté par  . Évalué à 3.

        >> Enfin ne revenons pas trop sur cette histoire de VM, qui a été une belle foire d'empoigne, mais perso j'espère que cette nouvelle VM -rmap du 2.6 sera enfin à la hauteur du reste du noyau ;-)) Ouais espérons que ces "empoignes" comme tu dis auront des effets positifs, parcequ'on a quand même perdu Alan Cox dans dans la bataille. Mais n'était-ce pas une excuse? Peut-être en avait-il marre d'être le maintener bénévole d'un des plus gros projets libres aux Monde ? Amour, gloire et beauté... :) Au fait Alan il était contre la rmap, c'est ça, ou c'est autre chose qui lui plaisait pas?

  • # Stratégie de remplacement

    Posté par  . Évalué à 1.

    je comrpendspas trop, je vois partout du LRU, je croyais que linux utilisais comme stratégie la méthode dite de la deuxième chance... a défaut d'un cours, vous savez ou trouvez de la documentation sur ceci, svp?

    • [^] # Re: Stratégie de remplacement

      Posté par  . Évalué à 4.

      Beaucoup d'OS essaient d'approximer le LRU (qui est assez difficile à implémenter exactement), ce que fait la VM d'andrea (linux 2.4.1x) je ne sais pas, vu qu'elle est très mal documentée.

      Pour de la docuementation sur les VMs de manières générales, je te conseille "Modern Operation Systems, 2ème édition" de Andrew S. Tanenbaum.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.