Journal Passage du noyau Debian 2.6.30-2 au noyau Vanilla 2.6.31-2

Posté par  (site web personnel) .
Étiquettes :
20
8
oct.
2009
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é.
  • # séparation

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

    Ton expérience est très intéressante. Mais moi ce que j'aimerai vraiment savoir c'est la part de gain liée à la "compilation + configuration aux petits oignons" et celle liées aux nouveautés du 2.6.31.

    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  (site web personnel) . Évalué à 3.

      Debian configure son noyau pour un serveur, c'est à dire en retirant la préemptabilité (donc les applications ne passent la main que quand elles le veulent, ou si vraiment trop de temps passe). Ça permet d'avoir des performances magnifiques sur un serveur, mais sur un desktop, dès qu'une appli utilise un peu de processeur (au démarrage par exemple), toutes les autres attendent. Ca produit l'effet du «démarrage en parallèle qui n'est pas parallèle» que je décris, les services s'attendant mutuellement.

      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  (site web personnel) . Évalué à 4.


        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 :-)


        regarde du côté de make localmodconfig et make localyesconfig
      • [^] # Re: séparation

        Posté par  . Évalué à 10.

        make bzImage && make modules && make modules_install && cp arch/x86/boot/bzImage /boot/linux-image-2.6.31.2

        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  . Évalué à 2.

          il peut aussi utiliser la destination make dep-pkg qui est sur le makefile du noyau vanilla :P
      • [^] # Re: séparation

        Posté par  . Évalué à 10.

        Debian configure son noyau pour un serveur, c'est à dire en retirant la préemptabilité (donc les applications ne passent la main que quand elles le veulent, ou si vraiment trop de temps passe). Ça permet d'avoir des performances magnifiques sur un serveur, mais sur un desktop, dès qu'une appli utilise un peu de processeur (au démarrage par exemple), toutes les autres attendent. Ca produit l'effet du «démarrage en parallèle qui n'est pas parallèle» que je décris, les services s'attendant mutuellement.

        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  (site web personnel) . Évalué à 5.

          J'ai aussi beaucoup aimé ce passage :

          > 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  (site web personnel) . Évalué à 1.

            C'était peut être pour montrer que le CPU est d'un ordre de grandeur technologique plus petit que celui du DD ^^

            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  . Évalué à 1.

          Quand il parle d'init, il parle peut-être du chargement du noyau, s'il a viré tous les modules et compilé en dur ce dont il a besoin, ça peut accélérer le boot.

          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  . Évalué à 4.

      dans la même veine que le journal, je viens de tester le dépôt liquorix ( liquorix.net ) qui propose un noyau à la pointe, orienté desktop, avec un certain nombre de patches pour améliorer la réactivité (par exemple ils ont intégré le BFS de Kon Kolivas :-), etc.

      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  (site web personnel) . Évalué à 2.

        Merci pour le lien ;)

        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  (site web personnel) . Évalué à 2.

          Nan bin en fait je vais retourner à mon kernel debian de base. Celui-là gère à priori plutôt mal mes ventilos. Mon portable a déjà surchauffé 2 fois (avec ralentissement puis arret pur et simple du PC).
          • [^] # Re: séparation

            Posté par  . Évalué à 1.

            J'ai testé 10 jours, et mon système est franchement lent !
            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  (site web personnel) . Évalué à 8.

    Salut,

    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  . Évalué à 2.

      Le 2.6.31 est aussi dans experimental (donc sur plein de miroirs).
  • # Ubuntu

    Posté par  . Évalué à 2.

    Pour les gens sous ubuntu, c'est possible de tester avec: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31.3/
  • # Et aussi...

    Posté par  . Évalué à 3.

    ...Peux-tu essayer de compiler ton propre noyau 2.6.30 ? Comme ça, tu pourras comparer avec le noyau officiel. Je suis curieux de savoir si KDE démarrera plus rapidement ou pas.
    • [^] # Re: Et aussi...

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

      Voici mon fichier .config : http://omploader.org/vMmk4aQ/.config .

      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  (site web personnel) . Évalué à 5.

        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é.


        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.

        > Une compilation prend vraiment beaucoup de temps,

        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  (site web personnel) . Évalué à 3.

          Merci 1000 fois pour la commande 'ionice".

          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  . Évalué à 1.

    Ce topic est très intéressant. Je suis justement récemment passe a Debian pour avoir un système stable et cohérent, c'est a dire ou les options de chaque package permettent au reste de fonctionner correctement, contrairement a un système compile soi-même ou on peut choisir les mauvaises options et arriver a des packages qui ne fonctionnent pas ou qui ne peuvent pas s'installer.

    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  . Évalué à 4.

      Tu peux trouver d'autres noyaux dans les dépots Backports. Par exemple, le 2.6.30 été ajouté récemment:
      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  (site web personnel) . Évalué à 2.

      >>> 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à.

      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  . Évalué à 1.

        C'est une erreur d'interprétation de ma part d'un message de GregKH il y a six mois qui disait que trois distributions importantes allaient se baser sur le 2.6.27, l'une d'elle étant SLES11, je pensais que la rhel6 serait une des deux autres, mais visiblement il parlait de F10.

        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  (site web personnel) . Évalué à 4.

          > mais çà veut dire que pour le noyau debian n'est pas plus stable que les distributions
          > 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  . Évalué à 2.

            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à).
            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  (site web personnel) . Évalué à 2.

              Les onduleurs ne tiennent pas 3 heures... Et puis, les pannes EDF m'ont fait une panne sur un gros onduleur !

              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  . Évalué à 2.

    Est-ce que quelqu'un aurait un VRAI bon tutoriel sur la compilation du kernel. Un truc récent, complet et intelligible (même en Anglais...). Avec des trucs sur l'optimisation, ce que l'on peux virer sans soucis etc.

    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  . Évalué à 5.

      Le mieux sans tutoriel c'est sans doutes de repartir du fichier de configuration du noyau fourni par ta distribution (/boot/config-2.6.trucmuche en général).

      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  (site web personnel) . Évalué à 3.

        > ça ne gagne quasiment qu'en temps de compilation

        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  . Évalué à 2.

      Il y a bien ça -> http://casteyde.christian.free.fr/system/linux/guide/online/(...)
      Il commence à se faire vieux mais ça peut toujours aider.
    • [^] # Re: Un tutoriel ??

      Posté par  (Mastodon) . Évalué à 4.

      lspcidrake -v

      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  . Évalué à 5.

    Active le dépot expérimental. Fais une recherche sur linux-image et tu verras que le noyau 2.6.31-trunk est dans expérimental.
    Comme ça tu pourras comparer.

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

Suivre le flux des commentaires

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