Le noyau 2.5.4 est sorti!

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
11
fév.
2002
Noyau
La dernière version du noyau vient de sortir...
Au menu pas mal de correction de bug, l'amélioration des versions sparc64, du système de fichier ext2...

A noter aussi:
- la mise en place d'un correctif permettant de prévenir dans le cas ou un processeur Athlon ne serait pas capable de faire du SMP.
- support pour le composant i810 d'Intel
- etc...

Note du modérateur : On nous signale aussi l'intégration de l'option "preempt" au stade du 2.5.4-pre6, option qui augmente la réactivité du système (cf. articles sur linuxdevices). Attention, il s'agit d'un kernel de Développement. Le dernier kernel Stable est le 2.4.17 (voire le 2.4.18-pre9). A réserver à ceux qui veulent être au courant des dernières évolutions (cf. le dernier lien, sur le statut du kernel).

Aller plus loin

  • # Experimental != Stable

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

    Je suis confus. Grand lecteur de linuxfr, j'ai remarque que des annonces importantes de versions stables (pas seulement kernel) passent en seconde page alors que des annonces de versions experimentales (comme celle-ci) arrivent en page principale.

    Un moderateur pourrait-il m'eclairer ?

    Steph

    • [^] # Re: Experimental != Stable

      Posté par  . Évalué à 10.

      Les changements dans le 2.5.4 sont assez importants (patch préemptif, ...) et l'URL sur le statut du kernel 2.5 n'était jamais passée ici, et elle peut intéresser beaucoup de monde.

      Il n'est pas nécessaire, AMHA, de passer une news par version du noyau (stable ou devel) mais en passer une de temps en temps (sur les deux branches) pour tenir au courant les lecteurs des évolutions est une très bonne chose.

      • [^] # News sur les nouvelles versions.

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

        Il n'est pas nécessaire, AMHA, de passer une news par version du noyau
        (stable ou devel) mais en passer une de temps en temps

        Sans vouloir relancer un troll poilu sur ce qui doit passer ou non en premiere page,
        _moi_, je pense que la sortie d'une nouvelle version du noyau devrait passer (en premiere page)
        ( mais pas forcement les x-pre??, effectivement).

        • [^] # Re: News sur les nouvelles versions.

          Posté par  . Évalué à 2.

          Non.
          Si tu veux être au courant de CHAQUE release, tu vas sur www.kernel.org.

          Eventuellement, une boite avec la dernière version du kernel et la date de sortie, si tu veux. Mais un news en première page _à_chaque_fois_ ... linuxfr n'est pas fait pour ça... !

          • [^] # Re: News sur les nouvelles versions.

            Posté par  . Évalué à 1.

            Ou alors un topic Kernel Relase, et la possibilité de désactiver certains topics pour ne pas les voir affichés sur la première page.
            Mais là, tu fous en l'air le système de cache, et ça apparaîtra quand même pour le visiteur anonyme.

          • [^] # Re: News sur les nouvelles versions.

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

            Je suis d'accord, mais je ne demande pas _forcement_ la premiere page, ni pour _chaque_ release (juste celle sans les -pre)

          • [^] # Re: News sur les nouvelles versions.

            Posté par  . Évalué à 3.

            Plus simple encore pour être prévenu : s'inscrire sur freshmeat. Rien que ce matin, j'ai reçu 11 mails de nouvelles versions de noyaux ! (2.5.4, 2.5.4pre1, 2.4.18pre9, 2.5.4pre2, 2.5.4pre3, 2.5.4pre6, 2.2.21pre2, 2.4.18-pre7-ac3, 2.0.40-rc2, 2.4.17-nsa1 et 2.5.3-nsa1)

            Pour s'inscrire, aller sur http://freshmeat.net/projects/linux/(...) et suivre le lien "Subscribe to new releases" dans la boîte grise du milieu à droite de la page. Pour cela, il faut bien sûr être enregistré sur freshmeat, mais qui ne l'est pas ?

    • [^] # Re: Experimental != Stable

      Posté par  . Évalué à 10.

      okay, je m'y colle, vu que je suis le responsable :)

      C'est la partie "preempt" qui m'a décidé à passer cette news en première page. Il s'agit d'un changement qui m'a semblé attendu par de nombreuses personnes (un peu comme quand ReiserFS fût le premiers système de fichiers journalisé, intégré dans un pre-x). Le thread sur son introduction il y a quelques semaines a été assez important (plus de 300 messages) sur la liste de diffusion du kernel.

      Sinon, il y a toujours le coté subjectif: "Je suis l'modéro, je passe c'que j'veux, na!" qui a dû jouer dans ma décision. :)

  • # patch preempt

    Posté par  . Évalué à 10.

    J'avais voulu essayer le patch preempt sur mon portable il y a un mois, mais avec ce patch un seul des 2 ports pccard fonctionne.
    Comme Robert Love a l'air de s'en foutre pas mal (du moins suite a mon mail sur linux-kernel, d'autres ont dit que c'etait pareil chez eux, tous avec des portables DELL d'ailleur, mais Robert ne s'est point manifesté), je voudrais savoir si d'autres ont le même probleme ici ?
    si cela se trouve il a corrigé le probleme, faut que je teste de nouveaux !!

    • [^] # ACPI :(

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

      En parlant de portable, j'attends que la liste ACPI termine le patch pour 2.5.4 (2.5.3 supporte actuellement) et la je le testerais sur mon portable.

      Steph

  • # patch kernel preemptible

    Posté par  . Évalué à 10.

    <troll>Histoire de changer des sempiternels commentaires sur les modérations/licenses/...</troll>, j'aimerais savoir si quelqu'un à fait des tests sur les performances du patch kernel preemption, et notamment sur l'affirmation de l'auteur du patch comme quoi la complexité (et donc l'overhead) liée à la gestion de ce mode était largement contrebalancé par la plus grande réactivité du scheduling ?
    Quelqu'un a t-il réalisé des manips avec le patch dans un environnement multi-processeur ?

  • # SMP

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

    Excusez moi de mon incultisme, mais c'est quoi le SMP ?

    • [^] # Re: SMP

      Posté par  . Évalué à 3.

      c'est un machine qui fonctionne avec plusieurs processeurs
      on oppose cela a l'amp ou il y a un maitre et des esclave

    • [^] # SMP

      Posté par  . Évalué à 8.

      Mon dieu qu'il est inculturé :)

      SMP = Symmetric Multi Processing. C'est quand tu as la faculté de faire *réellement* plusieurs traitements en même temps (pas seulement en les morcelant) C'est-à-dire que tu as plusieurs processeurs sur ta machine.

      Y'a aussi UP: machines mono-processeur. Les processus ont l'air de tourner en même temps, mais en fait ils se partagent juste des tranches de temps sur le même processeur.

      Allez hop, un petit howto pour la route: http://www.linuxdoc.org/HOWTO/SMP-HOWTO.html(...)
      En Francais: http://www.freenix.fr/unix/linux/HOWTO/SMP-HOWTO.html(...)

      Les gains sont:
      - plus grande réactivité
      - plus grande tenue en charge

      Attention: mort aux idées reçues! Un bi-P4 1GHz ne vaudra jamais un P4 2GHz, à cause de la surcharge de calcul induite par le fait qu'il y ait "plus de matos" à gérer, et que le processeur n'est en général pas ce qui ralentit la machine (mais plutôt tout ce qui est bus, disques...)

      • [^] # Re: SMP

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

        Attention: mort aux idées reçues! Un bi-P4 1GHz ne vaudra jamais un P4 2GHz, à cause de la surcharge de calcul induite par le fait qu'il y ait "plus de matos" à gérer, et que le processeur n'est en général pas ce qui ralentit la machine (mais plutôt tout ce qui est bus, disques...)

        ça dépend fortement des applis que tu lances sur ta machine, si c'est fortement // et indépendant, tu auras quasiment les mêmes performances, si tu as juste un programme de calcul, tu utilises un seul processeur.

        Mais ça peut être plus rapide si ta machine utilise bcp les procs pour les transferts, en effet, sur une mono-processeur, si tu scannes une image ton proc est monopolisé par les interruptions du port //, la souris devient asthmatique, la musique est hachée, etc...
        Sur un bi pro, un seul des 2 proc sera monopolisé.

        Pour une utilisation personnelle, il vaut mieux avoir un mono, pour une utilisation en serveur avec moulte processus en //, il vaut mieux du multi-processeur.

        Prenons l'exemple de déménageurs, tu as un déménageur qui peut soulever 100 kg il peut prendre 3 paquets, et 2 autres qui peuvent soulever 50kg chacun, ils ne peuvent prendre que 2 paquets à la fois (pour la gestion du multi proc).
        - Si tu n'as que des paquets de 25 kg, l'équipe des 2 déménageurs sera plus efficace (2x25)x2=100kg contre 3x25=75kg.
        - Si tu as des paquets de 33kg, le déménageur costaud sera plus efficace (33x1[66>50])x2 contre 3x33=99kg.

        Mais il est clair qu'il est plus facile d'exploiter à 100% un mono-processeur qu'un multi-processeur sauf usage particulier.

        Comme le calcul d'une même image 3D avec une ligne d'affichage par processeur où ils vont tapper dans des données communes, 2éme bonus comme ils auront les a peu prés les mêmes données dans le cache et que l'accés à la mémoire est 2 fois plus lent, ils pourront plus souvent accéder à la mémoire, et le bi-pro 500mhz sera plus rapide que le mono-pro 1ghz, c'est plutôt vrai dans les applis qui utilisent une donnée unique auquels on applique des traitements différents.

        D'aprés une feuille sur des prix au 4 février un PI@2.2 tourne a 1350 euros et 2 PIV@1.8 1280 euros, il faut compter le prix d'une carte bi-pro, mais on voit bien que pour application type "render farm" le bi-pro est bcp plus interessant économiquement.

        Maintenant pour fragger en 2048x1600 dans Quake III en faisant le benet avec sa machine de mort, point de salut monoproc PIV@2.2ghz geforce4 la plus onéreuse le tout "overclocké" d'au moins 50% plongé dans une cuve de fréon pour éviter le dégagement de chaleur équivalent à une centrale nucléaire :-)

        • [^] # Re: 2x500 Mhz > 1x1000Mhz

          Posté par  . Évalué à 3.

          le bi-pro 500mhz sera plus rapide que le mono-pro 1ghz
          Je crois que c'est faux ce que tu dis, dans le cas idéal (approchable mais jamais atteint), on a les performance que l'on aurait en additionnant les mégahertz mais jamais plus !

          Ce qui fait que l'on a toujours moins, c'est que de temps on a des conflits pour accéder à des ressources limitées, par exemple : le bus, un bloc de données protégé par un sémaphore qui est déja pris par l'autre processeur ... donc dès qu'il y a parallèlisme, il y a attente, d'où les fait que l'on soit toujours en dessous de la somme des mégahertz

          " calcul d'une même image 3D avec une ligne d'affichage par processeur ...le cas...où ils vont tapper dans des données communes... ils pourront plus souvent accéder à la mémoire..."
          Si je ne me trompe, en configuration multiprocesseur les accès mémoire sont justement plus lent qu'en uniprocesseur.
          En effet :
          - si les deux processeur font un accès lecture en même temps il y risque d'y avoir contention pour l'accès au bus si la bande passante de celui-ci ne couvre pas la somme des besoins des deux.
          C'est un problème important sur les architecture Intel, les architectures SPARC ont des bus beaucoup plus rapides. En fait, on se limite généralement à 4-8 voies sur Intel à cause de cela alors que sur SPARC ils vont jusqu'à 96 voies avec l'E15000.
          - il faut gérer la cohérence entre les différents caches, là j'avoue ne pas connaître le détail des algorithmes utilisé, mais celà ne peut que ralentir les choses à mon avis.

          • [^] # Re: 2x500 Mhz > 1x1000Mhz

            Posté par  . Évalué à 3.

            on a les performance que l'on aurait en additionnant les mégahertz mais jamais plus !
            Quand on a deux procs, on a aussi deux fois plus de cache, donc potentiellement moins d'accès à la mémoire. Dans ce cas, les performances peuvent être théoriquement supérieures au mono-proc, et de loin.

            • [^] # Re: 2x500 Mhz > 1x1000Mhz

              Posté par  . Évalué à 2.

              Oui uniquement dans le cas de la memoire, mais la pluspart des processus ne se limite pas qu'a l'acces à la mémoire (disques, cartes peripheriques...). Pour finir c'est pas parce que tu as deux voitures qui roulent à 100km/h que tu vas plus vite à demenager qu'une voiture qui roule a 200km/h, car la voiture qui va plus vite fera 2 aller/retour pendant que les 2 voitures n'en feront qu'un...

              • [^] # Re: 2x500 Mhz > 1x1000Mhz

                Posté par  . Évalué à 2.

                Il faut faire la distinction entre "peut" et "doit".
                Tout ce que j'ai dit, c'est qu'un biproc 500 peut être plus rapide qu'un monoproc 1000. Bien évidemment, c'est pas toujours le cas (en pratique, ce serait même plutot presque jamais le cas).
                C'était juste pour souligner que l'affirmation "un biproc 500 ne peut pas être plus rapide qu'un monoproc 1000" est à mon avis fausse.
                L'exemple que tu donnes n'est pas bon. Dans les deux cas, tu fais deux aller-retours dans le même temps (tu mélanges aller-retour et aller-retour par voiture).
                Dans tous les cas, il est déconseillé de conduire son camion de déménagement à 200 km/h :)

                • [^] # Re: 2x500 Mhz > 1x1000Mhz

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

                  Merci à tous pour vos réponses
                  D'une simple question est née un débat :)
                  Je vais remercier plus particulièrement Johann Deneux pour sa remarque sur le fait qu'il y avait deux fois plus de cache.
                  Je n'y avais pas du tout pensé
                  Kes k'on en apprend des choses sur linuxfr ...

Suivre le flux des commentaires

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