Bonjour,
Hier, j'ai eu envie de compiler et de tester le noyau Linux en version 2.6.31. Je regarde donc dans les dépôts de ma distribution, et découvre qu'il n'y est pas.
Tant pis, je me dis donc que je vais le compiler moi-même. Je récupère les sources, configure (en laissant la majorité des choix par défaut, ce qui compile beaucoup, mais ce n'est pas grave), et compile.
Une fois le noyau installé, je redémarre dessus. C'est d'abord un échec (pas de son, pas de souris USB, pas de composition). J'essaie de me débrouiller avec le clavier, et ajoute les modules nécessaires (en fait il faut simplement compiler USB en built-in pour la souris USB, compiler ALSA en built-in pour le son, et la composition, je ne sais pas, ça a marché miraculeusement).
Je recompile et réinstalle tout ça, je redémarre, et je peux enfin tester.
J'en suis encore étonné ! Jamais je n'ai vu mon système aussi rapide. Oui, on m'a dit que le noyau Debian est optimisé pour les serveurs, oui j'ai configuré le mien aux petits oignons, oui il paraît que la couche des pilotes en mode bloc a été largement améliorée, mais passer d'un KDE qui démarre en 2 minutes à un KDE qui démarre en 40 secondes (chargement de la session compris), ça, je ne le savais absolument pas !
C'est sur la même partition, le même matériel, la même libc, la même distribs, etc. Tout le démarrage est plus rapide et plus fluide (les services démarrent vraiment en parallèle, alors qu'avec le kernel Debian, on voit qu'ils s'attendent encore un peu). Tout ce qui est accès concurrent est largement meilleur (démarrage de Amarok + Konqueror + Kmail + Konsole (avec 8 onglets, donc 8 bash) et sous les services de KDE largement plus rapide).
J'ai également vu passer qu'une belle amélioration avait été ajoutée dans ext3 (que j'utilise encore sur mon /, merci Debian). Cette amélioration consistait à éviter des lourdeurs avec les ACL et tout un tas d'autre chose, ce qui rend le système de fichiers ext3 largement plus léger pour le CPU. J'ai justement un petit disque dur super rapide, et un CPU super lent (1,6Ghz, c'est peu par rapport au DD qui peut fournir 110Mio/s). Résultat : au démarrage de KDE, au lieu d'avoir mon CPU à 100% et le disque dur qui attend, le CPU est à 100% et le disque dur va au maximum.
Bref, j'ai toujours cru que toutes ces améliorations du noyau ne touchaient que très peu le desktop (quand on parle de la réduction d'une latence de 0,5ns, ça nous passe par dessus la tête), mais en fait pas du tout. Les moindres gains dans le noyau se répercutent directement sur le bureau, car le moindre goulet d'étranglement est utilisé des millions de fois.
J'ai donc maintenant un système réactif comme jamais, la composition qui marche, le KMS que je dois encore trouver comment activer, tout mon matériel détecté et qui marche, du son, ma souris, ma carte réseau, mon chipset, etc.
En clair, je suis heureux ! Merci aux développeurs du noyau pour nous fournir un travail d'une telle qualité.
Journal Passage du noyau Debian 2.6.30-2 au noyau Vanilla 2.6.31-2
8
oct.
2009
# séparation
Posté par HoloAddict (site web personnel) . Évalué à 10.
Autrement dit, aurait-je des performances a peu pret similaires si j'attends que le 2.6.31 rentre dans debian, ou faut-il que je me tape une compilation et optimisation de noyau (dont je n'ai vraiment pas envie...).
D'après ce que je lis par ci par la, l'optimisation des FS/ACL ne compterait qu'à auteur de 3% et le "desktop improvement" uniquement quand ta RAM est saturée. Donc j'aurais tendance à penser que tes amélioration de performances sont principalement dues à la configuration de ton noyau.
[^] # Re: séparation
Posté par steckdenis (site web personnel) . Évalué à 3.
L'horloge est réglée sur 100hz avec Debian, alors que la mienne est réglée sur 300hz. Cela permet également une meilleure réactivité. Ce sont à peu près les seuls changements que j'ai fait (j'ai fait un make xconfig, puis j'ai lu les petits messages de chaque option du premier groupe, puis j'ai sauté le reste parce que j'en avais marre).
Quand le noyau rentrera dans Debian, il sera normalement plus rapide que le 2.6.30, mais toujours orienté serveur. Il faudrait voir si Debian ne propose pas des variantes (il me semble que Ubuntu le fait avec ses noyaux -server, -rt et -desktop).
La recompilation est franchement rapide et simple (make bzImage && make modules && make modules_install && cp arch/x86/boot/bzImage /boot/linux-image-2.6.31.2), c'est juste la configuration qui nécessite d'être un peu attentif.
Quand j'aurai un peu de temps, je compte voir s'il est possible de créer une belle GUI de compilation du noyau pour KDE (gnark !) : cocher les grosses options (serveur/desktop, rapidité/robustesse par exemple), puis la GUI détecte les modules chargés (parse de lsmod), ainsi qu'éventuellement ceux qui sont compilés en dur (on fait comment ?), puis un kernel est téléchargé, configurer avec tout en N, puis en O tout ce qui est utilisé sur le système. Démarrage foudroyant, kernel léger et optimisé, etc :-) .
[^] # Re: séparation
Posté par pix (site web personnel) . Évalué à 4.
regarde du côté de
make localmodconfigetmake localyesconfig[^] # Re: séparation
Posté par khivapia . Évalué à 10.
euh pourquoi tu n'utilises pas make-kpkg plutôt ? C'est prévu pour prendre les sources vanilla, et en deux commandes (make-kpkg clean && make-kpkg --initrd kernel_image ) tu obtiens un paquet debian qui s'installe tout seul, en faisant attention aux entrées de grub et à la génération de l'initrd, et on peut le désinstaller facilement sans se poser de question.
[^] # Re: séparation
Posté par briaeros007 . Évalué à 2.
[^] # Re: séparation
Posté par ckyl . Évalué à 10.
Comme souvent, tu dis beaucoup de choses avec des mots compliqués. Le problème c'est généralement très approximatif ou complètement faux... Ici donc les applications ne passent la main que quand elles le veulent, ou si vraiment trop de temps passe en est un bel exemple.
CONFIG_PREEMPT permet d'activer ou de désactiver la préemption en mode noyau. Quand elle est désactivé, un thread ne peut pas être interrompu lorsqu'il se trouve en espace noyau. La main est passée à un autre processus (si besoin) au moment ou le thread repasse en espace utilisateur. Si tu as de long chemin d'exécution dans le noyau, alors tu peux avoir un petit manque de réactivité. Avec le CONFIG_PREEMPT, un changement peut s'exécuter alors que le thread est en espace noyau (sous certaines conditions). Par exemple tu peux réagir à une interruption. Quand un thread est en espace utilisateur ça ne change absolument rien.
Je serais bien étonné que CONFIG_PREEMPT change quoi que ce soit à la vitesse de la phase d'init. Cela dit je ne demande qu'à être convaincu...
Après un noyau, environnent de bureau, une distribution, une système de paquet en 6 mois tu passes maintenant à une GUI pour la compile noyau. Tu penses pas que tu devrais plutôt faire une chose correctement plutôt que tout et n'importe comment ?
[^] # Re: séparationj
Posté par Krunch (site web personnel) . Évalué à 5.
> J'ai justement un petit disque dur super rapide, et un CPU super lent
> (1,6Ghz, c'est peu par rapport au DD qui peut fournir 110Mio/s).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: séparationj
Posté par Hippie Geek (site web personnel) . Évalué à 1.
D'ailleurs moi je suis un exemple négatif : 1.6Ghz, c'est beaucoup par rapport au SSD qui peut fournir 3Mio/s (en pointe).
Donc contrairement a lui, c'est le proco qui attend que le ssd charge ce qui est a exécuter :-/
[^] # Re: séparation
Posté par ChickenKiller . Évalué à 1.
Maintenant, je suis d'accord, j'ai aussi l'impression que l'utilisateur essaye de décrire une sensation de réactivité plus importante ( et qui est sûrement réelle) en utilisant des approximations flagrantes.
Un simple «j'ai l'impression que ça va plus vite» aurait suffit, mais ça aurait été difficile de justifier un journal rien que pour ça (déjà que celui-ci est mortellement creux...). Je vois quand même une phrase utile : «Merci aux développeurs du noyau pour nous fournir un travail d'une telle qualité.». C'est vrai qu'on ne le dit jamais assez. :-)
[^] # Re: séparation
Posté par khivapia . Évalué à 4.
J'ai eu exactement les mêmes impressions, sur un PC un peu chargé (peu de RAM) la joie de retrouver la réactivité, par exemple rien que changer de fenêtre sous KDE ne prend plus 2 secondes mais c'est instantané... Bref c'est un bon compromis je pense pour qui ne veut pas se casser les pieds avec une recompilation (quoiqu'avec make-kpkg c'est un jeu d'enfant).
[^] # Re: séparation
Posté par HoloAddict (site web personnel) . Évalué à 2.
Avec ce kernel, j'ai en effet ressenti une amélioration globale de la rapidité (surtout en forte charge). Mais bon, au fond de moi j'espérais un peu mieux. Si je n'y avais pas prété attention je ne l'aurais peut-être pas remarqué.
Ceci dit je ne perds rien alors ça me va ;) c'est bon a savoir ^^
[^] # Re: séparation
Posté par HoloAddict (site web personnel) . Évalué à 2.
[^] # Re: séparation
Posté par byrad . Évalué à 1.
Par exemple je lis un flux et si j'ouvre en même temps une appli, la lecture se fige, alors qu'avec le noyau debian de base, je n'ai aucuns problèmes.
Bref, j'ai vu, et j'en suis revenu.
# Pourquoi?
Posté par niol (site web personnel) . Évalué à 8.
Quelles sont les différences entre ton .config et celui du noyau précompilé de Debian?
Observes-tu les mêmes différences de performance avec un 2.6.30 Vanilla? Je pose la question car tu sembles sous-entendre que le noyau précompilé de la distribution n'est pas adapté à ta machine et/ou à ton utilisation.
Enfin, observes-tu les mêmes améliorations avec un 2.6.31 précompilé? Tu peux le trouver à l'adresse suivante : http://kernel-archive.buildserver.net/debian-kernel (dès que ça sera revenu).
[^] # Re: Pourquoi?
Posté par Sylvain Sauvage . Évalué à 2.
# Ubuntu
Posté par ribwund . Évalué à 2.
[^] # Re: Ubuntu
Posté par steckdenis (site web personnel) . Évalué à 1.
Noon ! J'ai compilé la version .2 hier et je vois maintenant que la .3 est sortie. J'ai vraiment pas de chance (la dernière fois j'ai compilé un 2.6.28 quand le 2.6.29 était en rc, le temps de la compile, la version finale était sortie).
/hs
[^] # Re: Ubuntu
Posté par Smarter . Évalué à 5.
[^] # marche pas
Posté par Rémi baudruche . Évalué à 1.
les messages sont là : https://pastee.org/kq25f
[^] # Re: marche pas
Posté par ribwund . Évalué à 2.
# Et aussi...
Posté par polytan . Évalué à 3.
[^] # Re: Et aussi...
Posté par steckdenis (site web personnel) . Évalué à 2.
Je ne sais pas si je pourrai recompiler une autre version de mon noyau. J'ai un simple Atom à 1,6Ghz, et plein de choses à faire. Une compilation prend vraiment beaucoup de temps, temps pendant lequel je ne sais que surfer sur internet ... et pas compiler les programmes que je développe.
Si quelqu'un a une meilleure machine, ce serait effectivement intéressant de voir si c'est le changement de noyau ou la recompilation qui change tout.
PS: Mise à jour des données : redémarrage en quelques secondes à peine, mais le KDE prend plus ou moins 50 secondes à démarrer maintenant. La différence est du au fait que lors de mon premier test, Kate n'était pas lancé.
[^] # Re: Et aussi...
Posté par CrEv (site web personnel) . Évalué à 5.
Et voilà...
le truc c'est que si tu veux comparer des systèmes, il faut changer un seul paramètre à la fois... (et si tu veux convaincre faudrait le faire calmement plutôt que de partir tout le temps dans tous les sens...)
> Une compilation prend vraiment beaucoup de temps, temps pendant lequel je ne sais que surfer sur internet ... et pas compiler les programmes que je développe.
oué enfin, compiler c'est bien beau, mais tu peux ptetre aussi écrire du code, réfléchir à régler tes problèmes de dépendances par exemple, etc. Développer des programmes c'est pas que compiler...
[^] # Re: Et aussi...
Posté par ʭ ☯ . Évalué à 5.
Un conseil : ionice -c3 nice -20 make va changer ta vie... à moins que la RAM ne manque ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Et aussi...
Posté par Olivier (site web personnel) . Évalué à 3.
Je connaissais déjà "nice" pour la répartition des priorité CPU.
Mais "ionice -c3" ca change vraiment la vie lors des gros accès disques !
# un noyau plus stable pour debian ?
Posté par frz92 . Évalué à 1.
Je suis assez déçu par le noyau par défaut de lenny (le dernier 2.6.26 disponible) car j'ai eu pas mal de plantages lorsque j'utilise mon système de façon intensive avec des machines kvm. Je précise que je n'utilise que des packages de la branche stable, et que les plantages ne sont pas dus a un hardware défaillant.
Je suis justement passe a debian plutôt qu'une ubuntu pour avoir des cycles longs (comme rhel) afin d'avoir un système très stable, et je n'ai pas besoin d'avoir les dernières versions des packages. J'ai l'impression que le noyau debian est finalement assez proche du 2.6.26 vanilla, et qu'il n'y a pas beaucoup de patches, donc la stabilité est satisfaisante en environnement normal mais insuffisante en cas d'utilisation intensive, comme pour toutes les distributions de type desktop qui sortent deux fois par an.
Le noyau de rhel me semble tout de même avoir été travaillé beaucoup plus en profondeur, et on peut voir qu'il y a beaucoup de patches qui s'accumulent avec le temps, même s'ils ajoutent en partie des nouveautés. On peut voir les sources ici:
http://people.redhat.com/dzickus/el5/
Et aussi un document très intéressant qui compare les sources vanilla et rhel:
http://www.surriel.com/system/files/summit2009-riel-turtle-a(...)
Je pense donc que le noyau rhel/centos est largement plus stable, et je n'ai pas de problème particuliers avec les serveurs qui tournent avec redhat au boulot. Mais je n'ai pas envie de passer a Centos, car il y a beaucoup moins de packages (malgré les repositories comme EPEL), et que le noyau comporte beaucoup de limitations (on est notamment oblige d'utiliser ext3 car redhat ne supporte pas les alternatives comme reiserfs).
Je suis donc a la recherche d'un noyau aussi robuste que rhel, mais sur une debian et avec
des options moins réduites que sous rhel. J'ai donc cherche a récupérer les sources du noyau rhel, mais ce n'est pas évident de les compiler et de les utiliser dans un autre environnement que redhat. Notamment il y a beaucoup d'options non supportées par redhat qui ne compilent même pas si on les active. Ensuite, même une fois le noyau compile, j'ai eu un plantage au démarrage mais je n'ai pas été plus loin.
Il y a aussi le noyau vanilla 2.6.27 qui est particulièrement intéressant car il n'est pas
très ancien et il continue a recevoir des correctifs ce qui permet de continuer a améliorer la stabilité. Ce noyau servira d'ailleurs de base pour la rhel6 et SLES l'utilise déjà. Malheureusement debian a choisi de se baser sur un 2.6.26 dont le support officiel s'est arrête très vite, plutôt que 2.6.27.
Donc connaissez vous des dépôts alternatifs ou des projets permettant d'utiliser un noyau
précompilé et maintenu, installable sur debian/ubuntu, qui offre une stabilité supérieure
au noyau fourni par défaut ? Ca serait vraiment super d'avoir la possibilité d'utiliser
un noyau base sur les sources redhat, ou au moins des sources 2.6.27 récentes sur debian pour avoir un système vraiment robuste.
[^] # Re: un noyau plus stable pour debian ?
Posté par ZeroHeure (site web personnel) . Évalué à 4.
http://packages.debian.org/search?keywords=linux-image
Tu peux chercher sur apt-get.org
Tu peux faire un mix de stable et testing pour installer un noyau plus récent en faisant de l'apt-pining dans /etc/apt/preferences
Il y a un bon point de départ sur le wiki: http://wiki.debian.org/AptPinning
Tu peux compiler une version plus récente pour Lenny en t'aidant du paquet source de Debian Testing (il faudra modifier un peu).
Tu peux, même si actuellement on est au 2.6.30, tu peux trouver le 2.6.29 et le 2.6.28 dans les dépots archivés (me souvient plus du nom).
Et j'arrête là ma liste, bien qu'on puisse trouver d'autres possibilités en lisant les docs.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: un noyau plus stable pour debian ?
Posté par patrick_g (site web personnel) . Évalué à 2.
C'est sûr ça ? Tu a une source ? Moi je croyais que la future RHEL6 allait se baser sur le noyau de la Fedora 12.
[^] # Re: un noyau plus stable pour debian ?
Posté par frz92 . Évalué à 1.
Ca m'intéresserait d'avoir des infos sur la RHEL6, ou peut on trouver cette info ? Si elle se base sur F12, donc sur le 2.6.31, et que la finale sort au printemps 2010, ca fait six mois de stabilisation. Elle devrait proposer ext4 j'imagine, et il faudra attendre rhel7 pour btrfs.
A part çà j'ai fait un upgrade vers le 2.6.30 depuis lenny-backports, et ca semble être beaucoup plus stable pour kvm. Ca résout ce problème ci, mais çà veut dire que pour le noyau debian n'est pas plus stable que les distributions desktop qui sortent tous les six mois.
[^] # Re: un noyau plus stable pour debian ?
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
> desktop qui sortent tous les six mois.
Pourquoi tu généralise sur un seul paquet.
Peut être simplement, kvm n'est pas prêt en production sur une lenny. kvm évolue vachement et chez debian, stable veut dire correction de gros bogues, pas de modification de fond...
Sur lenny, j'ai pas une machine qui plante, ni un serveur sous xen, donc pour moi le noyau de lenny est très bien comme cela, et j'en ai des machines... Si je n'avais pas de panne électrique (merci EDF), j'aurais des uptimes supérieurs à 365 jours (sous etch, lenny n'a pas encore cet âge là).
[^] # Re: un noyau plus stable pour debian ?
Posté par briaeros007 . Évalué à 2.
Donc pas de mise à jour des noyaux ni d'onduleur? Parcequ'il y a eu qq failles sur le noyau ;)
(si elles sont qu'en réseau privé/controlé je suis d'accord que ce n'est pas forcément utile).
[^] # Re: un noyau plus stable pour debian ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Sinon, sur du réseau privé et sur des serveurs qui n'ont quasiment aucun module noyau, je préfère souvent laisser tel quel plutôt que de tout relancer. Souvent, les bogues noyaux peuvent entraîner des DoS, ce qui en interne est un risque très faible.
# Un tutoriel ??
Posté par nicko . Évalué à 2.
Les 3/4 des trucs que j'ai vu sont juste super minimalistes et une fois qu'on se retrouve devant l'écran de config, ben on laisse tout par défault parce qu'on sait pas ce que sait.
Les autres sont plus complets, mais vieux et obscurs...
Et du coup le kernel obtenu est pas optimisé du tout. Autant garder celui de la distrib....
[^] # Re: Un tutoriel ??
Posté par khivapia . Évalué à 5.
Les points importants dans une première approche sont précisés plus haut, à savoir sélectionner le bon processeur, choisir un noyau préemptible, à fréquence élevée, tout ceci se trouve dans les options "Processor type and features". Penser aussi à désactiver toute option de débuggage évidemment.
Ensuite, chaque option de configuration comporte quelques lignes de documentation, avec un petit coup de google c'est là qu'est le vrai tutoriel :-)
Enfin, en général une large majorité des options du noyau pour les distributions sont fournies sous formes de modules (et une large partie concerne les pilotes), ça n'impacte pas les performances, mais uniquement le temps de compilation.
Si tu veux enlever toutes les choses inutiles, la commande lshw liste le matériel présent sur ta machine et les modules nécessaires pour la faire fonctionner. Il est alors possible de compiler ces modules en dur dans le noyau et de désactiver l'initrd et même l'utilisation de modules tout court (mais c'est un peu hardcore et ça ne gagne quasiment qu'en temps de compilation).
Pour finir, là où on gagne encore plus selon l'utilisation qu'on veut faire de son noyau, c'est en utilisant par exemple des patches externes pour la réactivité (c'est ce que fait liquorix par exemple). À savoir qu'on risque de perdre en stabilité, et que la méthode à suivre est à trouver dans la documentation du patch en question.
[^] # Re: Un tutoriel ??
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Comme tu ne peux plus charger de module, tu élimines aussi une partie des rootkit si mes souvenirs sont bons.
[^] # Re: Un tutoriel ??
Posté par Spack . Évalué à 2.
Il commence à se faire vieux mais ça peut toujours aider.
[^] # Re: Un tutoriel ??
Posté par Mali (site web personnel) . Évalué à 1.
http://www.kroah.com/lkn/
[^] # Re: Un tutoriel ??
Posté par bubar🦥 (site web personnel) . Évalué à 4.
make mrproper
make
make modules
make modules_install
make install
et -surtout- passer plusieurs heures à LIRE l'interface (old,menu,x), à chaque fois : ne pas se presser, ne pas se dire "j en ai pas l'utilité donc je lit pas". Non lire, vraiment. Puis relire, à chaque version de noyau, afin de s habituer à l'organisation, et de repérer très vite les nouveautés. Après tu pourra attaquer directement le .config à base de scripts, car même là si tu fait une erreur, il te le dira.
Linux c'est génial.
Au passage, un grand merci à Stephane G (qui se reconnaitra) : les deux premières choses qu'il m' appris sur linux : les bonnes options (make mrproper n'était utilisé que sur Debian alors, il me semble), et la modification d'init{ramfs,rd}. Pour commencer avec linux, c'est formateur, et quel pied, linux ! Surtout quant le tout premier kernel compilé boot et fonctionne, et ne conserve que le support pour son matériel :-)
# le noyau 2.6.31-trunk est dans expérimental
Posté par ZeroHeure (site web personnel) . Évalué à 5.
Comme ça tu pourras comparer.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: le noyau 2.6.31-trunk est dans expérimental
Posté par pini . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.