Le noyau Linux 2.6.38 sera plus performant ou pas


Accélérer Ubuntu
Mike Galbraith vient de soumettre un patch de 384 lignes qui améliore sensiblement les performances du noyau Linux. Celui-ci sera sans doute disponible dans la version 2.6.38 du kernel. Il permet de réduire les temps de latence par 10 et augmentera donc au passage la réactivité du système, lors de grosses montées en charge du CPU.

Audi Linux

Bien que beaucoup de personnes se soient excitées lors de l'annonce de la sortie de ce patch (dont Linus Torvalds en personne), il faut savoir que ce dernier ne devrait au final pas changer grand chose pour l'utilisateur final.

En effet, ce patch permet de mieux gérer les performances quand des tâches lourdes sont exécutées, car il s'occupe de redistribuer les ressources système par groupe. Ainsi, sur une machine linux, si vous avez un groupe GUI (= applications graphiques) et un groupe compilation (ex: une console TTY sur /dev/pts/x), 50% des ressources CPU seront attribuées au premier et 50% au groupe restant.

Résultat, lorsque l'on lance une compilation dans un shell, on peut en même temps surfer sur Internet ou regarder une vidéo sans constater de ralentissement.

Le système est certes plus fluide, mais le revers de la médaille est que le processus qui consomme le plus de ressources s'exécutera beaucoup moins vite.

Mais l'aspect qui me semble le plus important, c'est que sur une distribution Linux orientée bureautique, Xorg est un TTY à lui tout seul. Or, toutes les applications graphiques seront dans le même groupe. L'utilisateur final n'y gagnera donc pas grand chose, même s'il lance Firefox et LibreOffice dans une même session. A moins que le concept du patch en question soit repris et amélioré par la suite...

Et puis, il ne s'agit pas vraiment d'une révolution, la commande nice (gestion des priorités des processus) permet de faire des choses similaires depuis bien longtemps :

nice +20 make &
nice -20 vlc big-buck-bunny.ogv

Bref, pour conclure, je dirais que ce genre d'amélioration est appréciable, mais uniquement pour les plus geeks d'entre nous. C'est à dire ceux qui compilent régulièrement leur noyau, tout en regardant un dessin animé avec des lapins blancs dedans. Ou alors pour la fana du multitâches, mais uniquement avec des applications très consommatrices de ressources (montage vidéo, calculs...).

Démonstration vidéo sans patch et avec.
Source


16 Commentaires pour "Le noyau Linux 2.6.38 sera plus performant ou pas"

Flux des commentaires de cet article Ajouter un commentaire
  •  

    Ce qui veut dire que si j'utilise BOINC, je ne gagnerais pas en rapidité?

    RépondreRépondre
    wido , le 17 novembre 2010 à 23:11
  •  

    @wido : c'est quoi BOINC ?

    RépondreRépondre
    pti-seb , le 17 novembre 2010 à 23:36
  •  

    Bouh vilain, tu viens de casser l'enthousiasme de tout un pan de la banquise ! :p

    RépondreRépondre
    JackDaniels93 , le 17 novembre 2010 à 23:38
  •  

    C'est un peu le même principe que pour le noyau de Vista/Win7 qui privilégie les processes multimédia sur le reste de façon automatique.

    Par contre je suis pas d'accord avec ton analyse sur "de toute façon tout est dans tty1"

    Chiche de faire un programme qui modifie le "nice" de façon automatique :D

    BOINC c'est un soft de calcul partagé pour des progets scientifiques

    RépondreRépondre
    zo3 , le 17 novembre 2010 à 23:52
  •  

    @JackDaniels93 : mon but n'est pas de casser la banquise. Juste de définir quelles sont les conditions exactes qui feront que ce patch sera utile ou non. A lire la plupart des sites qui reprennent la news, on dirait que Linux va être plus performant dans toutes les conditions. Ce qui est, à mon avis, pas vrai.

    @zo3 : c'est vrai que la commande nice ne permet pas l'ajustement automatique de la priorité. La modification de Mike Galbraith permet de tout automatiser. Ça évite de la faire à la main, c'est un réel avantage.

    @wido : Pour BOINC, je ne sais pas trop comment il fonctionne. Il faudrait l'avis d'autres personnes pour savoir si le patch sera utile pour ça ou pas.

    RépondreRépondre
    pti-seb , le 18 novembre 2010 à 00:00
  •  

    Projet de recherche: http://www.boinc-af.org/les-sites-des-projets.html

    Le but est de faire avancer la recherche dans tous les domaines (astrologie,biologie,maths,..) pour cela tu as besoin des ressources non utilisés de ton pc (90%) et de t'attacher à un projet que tu auras choisi ensuite tu es classé au niveau mondial, et en faisant équipe avec l'alliance francophone on devient plus puissant.

    Voici mes stats: http://statsbzh.boinc-af.org/user.php?cpid=5d532b6cb48cc7a519d4c7e363565e8f
    c'est peut-être modeste, mais j'aime

    RépondreRépondre
    wido , le 18 novembre 2010 à 00:10
  •  

    Effectivement, j'ai vu la news sur korben, et je me suis empresser de patcher mon noyau et de le tester. C'est vrai qu'on ne voit aucune amélioration de vitesse, et pour cause quand on en as l'explication.
    Personnellement je préfère que la tache se fasse au plus vite pour passer au reste, et même une compilation de noyau ne fait pas ramer mon Linux, donc bon ...

    RépondreRépondre
    Droïde , le 18 novembre 2010 à 01:05
  •  

    De ce que je crois comprendre de ceci :
    http://en.wikipedia.org/wiki/Cgroup

    Il y a un cgroup par défaut pour le réseau d'où le fait que Linus parle d'affichage de page web. Par contre aucun rapport avec les TTY (tu remarqueras par exemple que dans la vidéo d'exemple la compilation et les autres appli sont dans un même TTY), il est possible que la compilation seretrouve dans un cgroup pour les IPC.

    Au passage tu remarqueras que Linus dis clairement que (« there's clearly
    enough of a CPU load when loading a new web page that if you have a
    load average of 50+ at the same time ») ça se vois quand tu as un load average à supérieur à 50 (perso je n'ai jamais eu un load average aussi élevé). On peut voir cette valeur avec les commande uptime ou top (ou htop). Pour avoir un load average aussi élevé il faut avoir 50 processus **qui demandent la main au processeur en même temps** (le plus que j'ai fais c'est 32).

    @Droïd > lance la compilation en multi-threadée (genre deux fois le nombre de core que tu possède) tu comprendras. Par défaut il y a un processus pour la compilation donc il est facilement gérable par le noyau actuel car il gère une équitée entre les processus (si tu as n processus demandant accès au CPU la compilation auras droit à 1/n par des tes ressources pour faire simple) si tu en lance 64 pour la compilation tu alouras 64/n par de tes ressources. D'après ce que j'ai compris tout le principe du patch c'est que le noyau puisse avoir connaissance des regroupement de processus et qu'il les prennent en compte.

    RépondreRépondre
    MisterFreez , le 18 novembre 2010 à 02:27
  •  

    no

    RépondreRépondre
    Jacky , le 18 novembre 2010 à 08:44
  •  

    @MisterFreeze : l'élément qu'il te manque, c'est que quand tu lance un shell, il crée un tty virtuel (pts/X) tu peux lancer un "who" sur ta machine pour t'en rendre compte.
    Donc une compilation lancée depuis un terminal (même dans X) bénificiera de l'auto-groupage de ce patch. Par contre, LibreOffice ou Firefox ne créent pas de tty virtuel donc seront dans le même cgroup (celui du TTY de X)

    RépondreRépondre
    Aissen , le 18 novembre 2010 à 10:42
  •  

    @Aissen @MisterFreez : par contre l'astuce, c'est d'ouvrir deux shells en mode graphique et de lancer Firefox dans l'un et LiberOffice dans l'autre. Et là tu vas bénéficier des améliorations. Bref, le truc que personne ne fera.

    Tout ça ajouté au load average à 50, confirme que cette amélioration ne concernera que quelques utilisations bien spécifiques.

    RépondreRépondre
    pti-seb , le 18 novembre 2010 à 12:14
  •  

    @pti-seb: à condition que Firefox ou LibreOffice soient multi-process (comme c'est le cas pour chrome) . Il seront alors gérés par le scheduler comme une seule entité(dans le même cgroup), ce qui permettra d'être plus juste au niveau des latences par rapport aux autres processus.

    RépondreRépondre
    Aissen , le 18 novembre 2010 à 13:14
  •  

    Un article intéressant
    http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html

    Toute amélioration est bonne à prendre.

    RépondreRépondre
    Protux , le 19 novembre 2010 à 00:39
  •  

    Je me sert pas mal de machines virtuelles (parfois plusieurs à la fois), ce patch m'intéresse donc fortement !

    RépondreRépondre
    Vincent , le 19 novembre 2010 à 09:37
  •  

    Aucun impact sur boinc car il est de base en nice 19

    RépondreRépondre
    zo3 , le 19 novembre 2010 à 10:58
  •  

    Cela rassure

    RépondreRépondre
    dots , le 25 novembre 2010 à 18:41
 

Ajouter un commentaire

actualité android apache apple astuce astuces bash bilboblog blog boot chrome clavier commande commandes conky date debian Desktop développement elementary exploit faille fedora firefox flash gimp gnome google graphique Graphisme hack hacking Hardware humour intel internet iphone jailbreak Jeux Kde kernel libre Linux log logiciels Logiciels Libres lucid lynx maemo mail maquette metasploit microsoft mobile mockup monitoring mozilla multi-touch musique mysql n900 nautilus nokia noyau openoffice open source password photos php Planet publicité red hat redhat rpm réseau screenshot script serveur serveurs shell sql ssh statistiques sysadmin system Sécurité thème tux-planet tv twitter ubuntu unity vidéo vidéos vlc voyage wallpaper windows wordpress yum