Utilisez pleinement votre processeur pour compiler votre Kernel

J’ai récemment fait l’acquisition d’un processeur Intel I7 et ai donc pu me remettre confortablement à la compilation de mon Kernel. Il faut dire qu’entre un vieux Pentium D malade et un Atom N280, la compilation n’était pas vraiment pratique. J’ai vu directement une belle amélioration en termes de temps de compilation, mais je me suis aussi rendu compte en prêtant attention à l’usage CPU que seul un thread travaillait alors que j’en ai huit à ma disposition… Après discussion sur le channel irc #generation-debian, on m’a parlé (merci à n3os et pitcat) d’une ligne à rajouter dans le fichier kernel-pkg.conf situé dans /etc. Cette ligne permettant de faire travaillé un peu plus le CPU en augmentant le nombre de threads travaillant sur cette tâche.

Voici cette ligne : CONCURRENCY_LEVEL = valeur. La valeur étant le nombre maximum de threads (+1) pouvant travailler ensemble.

Pour connaître cette valeur, qui dépend de votre système, il y a une commande à entrer qui ressortira la valeur maximum vous concernant. La voici :

echo $(($(grep -c processor /proc/cpuinfo)+1))

Il vous suffit une fois votre valeur trouvée de modifier (en root) le fichier /etc/kernel-pkg.conf et d’y ajouter la ligne CONCURRENCY_LEVEL = valeur_trouvée puis de le sauver.

Il ne vous reste plus qu’à compiler votre kernel et vous constaterez bien vite une différence. Personnellement, sur un kernel non optimisé je suis passé de 1h environ à à peine 10 minutes et ai vu tous les threads du I7 à l’ouvrage.

Bonne compilation!

11 réponses sur “Utilisez pleinement votre processeur pour compiler votre Kernel”

  1. Épargnons les tuyaux : $(($(grep -c processor /proc/cpuinfo)+1))

    (Compte-moi les occurrences, et ajoute un, ça me semble un poil plus lisible. ;))

  2. @Kibi : Plus lisible en effet, mais à mon avis ta commande est mal passé à l’encodage sous wordpress, ne serait-ce pas plutôt

    echo $(($(grep -c processor /proc/cpuinfo)+1))

    parce que j’ai bien un retour de 9 chez moi mais comme ceci sans le echo « bash: 9 : commande introuvable » donc je présume qu’il est mal passé…
    Merci pour la commande en tout cas, je modifie le tout 😉

  3. Excellente astuce de configuration pour profiter pleinement de la puissance de ton monstre ! 😉 Rien à dire de plus vu que j’ai pas re-compiler un kernel (fonctionnel) depuis le dernier déluge mais ça m’a l’air au poil.

  4. @ktr : Il semblerait, du moins c’est ce que j’ai compris et ce qui est expliqué par ici (https://help.ubuntu.com/community/Kernel/Compile#Alternate%20Build%20Method:%20The%20Old-Fashioned%20Debian%20Way) qu’avec make-kpkg (qui est la méthode que j’utilise), on doit utiliser la méthode CONCURRENCY_LEVEL. Mais si tu préfère ne pas modifier le fichier, il y a toujours la méthode « export CONCURRENCY_LEVEL=valeur » avant la compilation.
    Maintenant dans le man il y a en effet une option

    --jobs = numéro

    qui fixe aussi cette variable… 2 ecoles? Celle du fichier et celle du –j ?

  5. Moi aussi je connaissais plutôt la technique du make -j x

    Par contre je comprend pas pourquoi le + 1 ?

  6. @Nico : La dessus c’est deux écoles aussi… Certains prétendent que c’est nombre de coeur (ou threads), d’autre ce nombre +1. J’ai trouvé un mini bench (http://forums.debian.net/viewtopic.php?t=33960) qui montre que ça augmente le temps de faire n+1 plutôt que n mais il faudrait tester ça sur plusieurs machines… Mais certains disent que le fait de faire n+1 permet à tous tes cores de travailler même si un process est en attente…
    C’est un peu à tester quoi…

  7. A une époque où les coeurs n’étaient pas si nombreux, une recette miracle proposé de faire un make -j4 (ou équivalent). La raison est toute simple : compiler du C déclenche énormément d’entrée-sortie (lecture des .h) et d’un .c à l’autre, le compilo recommence.

    Maintenant, avec les monstres multi-coeur, il est probable que multiplier ce nombre par 4 saturerait certainement les disques.

  8. @Guyou : Passer outre le nombre de threads dispo, il y a sans doute un risque… Maintenant j’ai testé avec un CONCURRENCY_LEVEL = 9 sur un caviar black et le disque tenait encore largement le coup.. Et ça m’a permit de diminué mon temps de compilation par 5 au moins…
    Après c’est à tester sur un SSD tiens cette méthode de passer outre le nombre de threads…
    Une autre méthode applicable aussi est la compilation dans un tmpfs, qui permettrait de gagner un peu de temps et si il y a suffisamment de mémoire (mais il en faut déjà une certaines quantitée) de prêter moins attention à ce problème d’I/O du disque…

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.