# [Portage] Parallel builds

## d2_racing

Vous avez pris connaissance de ça dernièrement ? : http://planet.gentoo.org/developers/zmedico/2008/07/23/portage_parallel_builds

----------

## Dismantr

Waow, ça a l'air pas mal ! je pense que je vais tester ça bientôt ! Quelqu'un a déjà mis ça en place ?

----------

## xaviermiller

hmm oui j'ai vu, mais il faut alors penser à changer MAKE_OPTS en conséquence

----------

## d2_racing

Si quelqu'un test le nouveau truc de Portage, j'aimerais biens savoir si on voit vraiment une différence.

----------

## ghoti

 *XavierMiller wrote:*   

> mais il faut alors penser à changer MAKE_OPTS en conséquence

 

Que veux-tu dire exactement ?

Comment interpréter ce post de zmedico ? 

 *zmedico wrote:*   

>  Comment from: Zac MEDICO [Member] Email · http://dev.gentoo.org/~zmedico/
> 
> Yes, MAKEOPTS is completely separate. The --jobs, --keep-going, and --load-average emerge options are analogous to the ones provided by make. They have the same meaning for both tools, but they are controlled separately. The make options are set via MAKEOPTS, while the emerge options are controlled via the emerge command line or via an EMERGE_DEFAULT_OPTS setting in /etc/make.conf. 

 

----------

## xaviermiller

je veux dire que si tu augmentes le nombre de builds parallèles, il faut diminuer le make-opts. Sinon, tu te trouveras avec max (nombre de builds) x (MAKE_OPTS), ce qui va mettre ta machine sur les genoux.

----------

## ghoti

La charge, oui, ça paraît clair !  :Wink:  (quoique un bon nice ...)

Mais quel est l'intérêt de --jobs ? Quel intérêt d'emerger plusieurs paquets en paralèlle puisque MAKEOPTS permet déjà de lancer des make en paralèlle ?

Bon, MAKEOPTS permet plusieurs processus paralèlles au sein d'un même paquet tandis que --jobs concerne plusieurs paquets (si j'ai bien compris  :Confused: ) mais quel intérêt de privilégier une méthode plutôt que l'autre ?

Le véritable intérêt ne concernerait-il pas surtout les multicores (meilleure répartition de la charge sur les # procs ?)

Ou alors, pour répondre au fait que certaines applications ne supportent pas la compilation multithread ?

Désolé pour ces questions naïves : je suis en pleine découverte !  :Wink: 

----------

## kopp

 *ghoti wrote:*   

> La charge, oui, ça paraît clair !  (quoique un bon nice ...)
> 
> Mais quel est l'intérêt de --jobs ? Quel intérêt d'emerger plusieurs paquets en paralèlle puisque MAKEOPTS permet déjà de lancer des make en paralèlle ?
> 
> Bon, MAKEOPTS permet plusieurs processus paralèlles au sein d'un même paquet tandis que --jobs concerne plusieurs paquets (si j'ai bien compris ) mais quel intérêt de privilégier une méthode plutôt que l'autre ?
> ...

 

Bah, certain paquets sont limités sur MAKEOPTS par exemple.

Effectivement c'est pour des multiproc multicoeur  :Smile: 

sinon : http://jolexa.wordpress.com/2008/07/24/gentoo-portages-new-jobs-feature/

----------

## ghoti

 *kopp wrote:*   

> Bah, certain paquets sont limités sur MAKEOPTS par exemple.
> 
> Effectivement c'est pour des multiproc multicoeur 

 

Ouf, pas encore trop largué le vieux !  :Laughing: 

Très instructif ton lien, Kopp ! Notament, la question du "./configure" : c'est vrai que certains peuvent être très longs !

----------

## geekounet

Je suis en train d'essayer, avec un MAKEOPTS="-j3" et --jobs=3 --load-average=5.0, et ça tourne plutôt bien. Ce qui est bien avec le --load-average, c'est que bien que j'ai demandé 3 emerge parallèles, il en fera moins si la charge devient trop haute pour mon ptit C2D, plutôt pratique.  :Smile:  C'est passé dans mon EMERGE_DEFAULT_OPTS du coup  :Razz: 

Et j'aime bien l'affichage résumé que ça donne, sans les lignes de compilation qui défilent et tout, c'est bien mieux pour suivre le déroulement de tout ça  :Smile:  Et ça affiche tout de même tout le log si jamais une compilation échoue, du coup ya pas de perte en cas de problème.  :Smile: 

----------

## Dismantr

Pourquoi avoir choisi un load-average de 5 ?   :Surprised: 

----------

## xaviermiller

ah ok, ça m'intéresse !

----------

## geekounet

 *Dismantr wrote:*   

> Pourquoi avoir choisi un load-average de 5 ?  

 

Heu, c'est juste arbitraire, ça tourne encore bien avec cette charge là, et mon laptop chauffe déjà bien assez comme ça  :Razz: 

----------

## Dismantr

Je n'ai pas compris comment ça marche ce taux de charge ; ça correspond à quoi exactement (ptite formule mathématique, si possible...) ? C'est le ratio de quelque chose, mais de quoi...   :Question: 

Sinon, quel intéraction y a-t-il entre ce load average et un PORTAGE_NICENESS="10" dans le make ?

Et quel intéraction y a-t-il exactement entre un j5 dans le make et le jobs= de la commande ?

Si je règle le load average, je supprime le niceness ?

Si je règle, comme geekounet, mon j5 sur j3 et jobs=3 ça implique quoi exactement, en terme d'emerge ?

----------

## geekounet

 *Dismantr wrote:*   

> Je n'ai pas compris comment ça marche ce taux de charge ; ça correspond à quoi exactement (ptite formule mathématique, si possible...) ? C'est le ratio de quelque chose, mais de quoi...   

 

Load average  :Wink: 

 *Dismantr wrote:*   

> Sinon, quel intéraction y a-t-il entre ce load average et un PORTAGE_NICENESS="10" dans le make ?

 

Aucune, le nice n'intervient que sur l'utilisation des CPU, pas sur la charge.

 *Dismantr wrote:*   

> Et quel intéraction y a-t-il exactement entre un j5 dans le make et le jobs= de la commande ?
> 
> Si je règle le load average, je supprime le niceness ?
> 
> Si je règle, comme geekounet, mon j5 sur j3 et jobs=3 ça implique quoi exactement, en terme d'emerge ?

 

Le -j5 dans le MAKEOPTS c'est le nombre de travaux simultanés que va lancer make dans la compilation d'un package, le --jobs d'emerge c'est le nombre d'emerge effectués en simultané, donc si t'as -j5 dans le MAKEOPTS et --jobs=3 pour emerge, ça te fait au max 15 compilations simultanées, ce qui fait pas mal monter la charge, donc c'est là que l'option --load-average d'emerge est utile, parce qu'il ne va pas lancer trop d'emerge simultanés si la charge devient trop haute, il limitera à 1 ou 2 emerge en fonction... Et là tu vas te demander quel intérêt dans ce cas si c'est au final ça fasse moins de compilation parallèle que prévu à la base ? Bah c'est genre que pendant qu'un package perd du temps considérable sur un ./configure ou sur de la copie de fichiers en fin d'install et tout, t'atteint pas forcément les 15 compilations simultanés qui te tuent la charge, les autres packages profitent quand même de leur -j5 et peuvent compiler joyeusement tranquillement, donc ya un gain de temps et tout... (j'ai du mal à m'exprimer sur la chose, j'espère que t'arrives à voir où je veux en venir ;p).

Et sinon, nan, comme expliqué plus haut, le niceness n'a rien à voir avec la charge, donc l'option --load-average ne dispense pas du PORTAGE_NICESS dans le make.conf, ce nice te permet toujours de déprioritariser les travaux d'emerge par rapport aux autres activités de ta machine, ce qui te la garde réactive.

----------

## Dismantr

Ok, merci !  :Smile: 

Mais alors, pourquoi, si on suit Wikipédia sur le load average, ne pas mettre 2 plutot que 5 ? 5, ça correspond à la charge en simultané que peut support 5 processeurs à un instant donné, non ? Quel intérêt à maintenir une file d'attente ? (2.0=les deux proc pris à 100%, si j'ai bien compris) ?

... Je sais pas si je suis très clair, là...

----------

## xaviermiller

hmm, pourquoi ne pas déplacer cette section "portage & parallel emerge" dans un vrai sujet, voire TIP ?

----------

## Leander256

Génial! C'est quand même une fonctionnalité que j'attendais depuis des siècles (bien que n'ayant du dual core que depuis un an et demi)! Parce qu'on perd un temps fou dans les parties non parallélisables comme les ./configure, surtout depuis le morcellement du serveur X en dizaines de paquets.

Ce qui me fait un peu peur, c'est la consommation mémoire de g++ sur certaines compilations. J'ai mis à genoux ma machine de 4 Go en compilant kmail avec un azureus bien chargé et un virtualbox faisant tourner une session de 1 Go. Donc si jamais portage a le malheur de compiler kmail en même temps que wesnoth par exemple, ça risque d'être le drame!

----------

## geekounet

 *Dismantr wrote:*   

> Ok, merci ! 
> 
> Mais alors, pourquoi, si on suit Wikipédia sur le load average, ne pas mettre 2 plutot que 5 ? 5, ça correspond à la charge en simultané que peut support 5 processeurs à un instant donné, non ? Quel intérêt à maintenir une file d'attente ? (2.0=les deux proc pris à 100%, si j'ai bien compris) ?
> 
> ... Je sais pas si je suis très clair, là...

 

Faut voir l'impact de la charge sur ta machine, en fonction de ton utilisation ça va pas forcément t'affecter. Perso ça m'arrive souvent de faire monter la charge de mon laptop à 10 et tout va bien, et j'ai déjà vu un serveur au boulot qui, à cause d'un daemon foireux qq part, était monté à plus de 300 de charge, et il restait pourtant tout autant réactif pour le boulot qu'il faisait ;p

Donc moi, je limite à 5 parce que je trouve ça suffisant pis voilà, question de choix personnel  :Smile: 

----------

## d2_racing

J'aurais jamais pensé que cette nouvelle ferait autant de posts  :Razz: 

----------

## Ezka

 *Leander256 wrote:*   

> Ce qui me fait un peu peur, c'est la consommation mémoire de g++ sur certaines compilations.

 

Essaye de compiler Boost ... avec un -j6 ... t'as besoin de rien d'autre pour flinguer 3Go de RAM   :Arrow: 

Donc en gros en mettant --jobs 6 --load-average X on se retrouve avec 6 compilation de paquet en // avec autant de thread de compil pour chaque compilation spécifié dans le MAKEOPTS (soit dans mon cas ça ferait 36 ... beau avoir un quad, vais tirer le tout vers le bas /D ) ?

----------

## xaviermiller

ou OpenOffice...

Bon, on se le splitte, ce thread-in-ze-thread ?

----------

## Dismantr

Ouais, c'est vrai ça !  :Mr. Green:  : Geekounet ? Yoyo ? KernelSensei ?    :Crying or Very sad:  nirf, y'en a qui ont des vacances   :Crying or Very sad:   :Crying or Very sad:   :Crying or Very sad:   !

 :Mr. Green:   :Mr. Green:   :Mr. Green: 

----------

## geekounet

Ouais heureusement que j'ai des vacances hein  :Laughing: 

C'est fait  :Wink: 

Et au passage, pour ceux qui l'ont toujours pas vu, ya plein d'autres nouveaux features dans Portage 2.2  :Wink:  (ya les sets qui sont intéressant et dont on avait causé auparavant ici, et le preserve-rebuild est sympa aussi mais il a encore qq bugs...)

----------

## mrpouet

 *Leander256 wrote:*   

> Génial! C'est quand même une fonctionnalité que j'attendais depuis des siècles (bien que n'ayant du dual core que depuis un an et demi)! Parce qu'on perd un temps fou dans les parties non parallélisables comme les ./configure, surtout depuis le morcellement du serveur X en dizaines de paquets.
> 
> Ce qui me fait un peu peur, c'est la consommation mémoire de g++ sur certaines compilations. J'ai mis à genoux ma machine de 4 Go en compilant kmail avec un azureus bien chargé et un virtualbox faisant tourner une session de 1 Go. Donc si jamais portage a le malheur de compiler kmail en même temps que wesnoth par exemple, ça risque d'être le drame!

 

Heureux de constater que je ne suis pas le seul a avoir des performances étranges lors de certaines compilations, notamment qt4 l'autre jours je suis monté jusqu'a 95% de la ram utilisée (1go de DDR2 au total) avec seulement un terminal + xchat, je me suis retrouvé du coup swapé à 25 %.

le plus étrange c'est que avec gcc je dépasse pas les ~35-40%, niveau cpu par contre çà tourne normalement , mais coté mémoire qu'est ce que çà bouffe.

le coup de l'emerge en parallel peut être intérèssant pour gcc celà dit à tester   :Wink: 

----------

## _Seth_

J'ai pas de multicoeur/multiproc, par contre l'option --keep-going me semble vraiment sympa. Fini les compils qui s'arrêtent pour un paquet qui foire et même plus besoin d'écrire un script ! J'ai hâte de pouvoir l'utiliser  :Wink: 

----------

## ghoti

 *_Seth_ wrote:*   

> J'ai pas de multicoeur/multiproc, par contre l'option --keep-going me semble vraiment sympa. Fini les compils qui s'arrêtent pour un paquet qui foire et même plus besoin d'écrire un script ! J'ai hâte de pouvoir l'utiliser 

 

+1 pour --keep-going : c'est vrai qu'elle est passée un peu dans l'ombre dans ce thread !

En expérimentant, j'ai aussi apprécié la possibilité de faire des "sets" d'ebuild : 

pour mon propos, j'ai utilisé un set de 10 ebuilds quelconques que j'installe/désinstalle avec emerge [param] @ma-liste-test.

Très pratique !  :Smile: 

Note bien que si --jobs/--load-average est particulièrement efficace sur les multicoeurs, cela ne veut pas dire pour autant que ton monocore n'en tirera aucun bénéfice ! Le mieux est d'essayer !  :Smile: 

----------

## _Seth_

 *ghoti wrote:*   

> Note bien que si --jobs/--load-average est particulièrement efficace sur les multicoeurs, cela ne veut pas dire pour autant que ton monocore n'en tirera aucun bénéfice ! Le mieux est d'essayer ! 

 

Je me retiens pour l'instant, dès que j'ai fini de rédiger ma thèse, je ferais chauffer mon mono-coeur !

----------

## Ezka

Ha j'avais pas remarqué, mais B2 'world' does no longer include 'system' ; donc une maj du world ne mettra plus à jour les paquets system si je comprend bien.

Il faut visiblement faire : emerge --update all-installed

----------

## kopp

Il va falloir changer nos habitudes de commande pour la mise à jour !

_Seth_ : roh c'est du réchauffé l'excuse de la thèse, y a Mickaël qui nous l'a déjà sorti ce mois-ci  :Smile: 

----------

## geekounet

 *Ezka wrote:*   

> Ha j'avais pas remarqué, mais B2 'world' does no longer include 'system' ; donc une maj du world ne mettra plus à jour les paquets system si je comprend bien.
> 
> Il faut visiblement faire : emerge --update all-installed

 

Ou emerge --noreplace @system pour que ça l'inclut dans world  :Wink: 

----------

## ghoti

Et dire qu'il va falloir expliquer tout ça aux n00bs !  :Rolling Eyes:   :Laughing: 

----------

## CryoGen

Ca me redonnerait presque envie de quitter paludis ^^ 

Mais non   :Arrow: 

(le "keep-going" je l'ai depuis un bout de temps   :Cool:  Les sets aussi il me semble, pour les jobs c'est jolie mais j'ai pas de dualcore :'( )

----------

## xaviermiller

tiens, si je fais un "emerge --deep --update --with-bdeps --newuse world", j'ai constaté que system était à jour, enfin, je changerai mon appel à "emerge --update" qui est dans mon historique bash  :Wink: 

----------

## Ezka

 *geekounet wrote:*   

> Ou emerge --noreplace @system pour que ça l'inclut dans world 

 

Oué mais tu perds un peu l'intérêt du nouveau systeme de "set", et puisqu'il y a un set prédéfini qui te fait la même chose ...

Bon aprés les goûts et les couleurs de chaqu'un   :Laughing: 

----------

## geekounet

 *Ezka wrote:*   

>  *geekounet wrote:*   Ou emerge --noreplace @system pour que ça l'inclut dans world  
> 
> Oué mais tu perds un peu l'intérêt du nouveau systeme de "set", et puisqu'il y a un set prédéfini qui te fait la même chose ...
> 
> Bon aprés les goûts et les couleurs de chaqu'un  

 

Ouais mais nan, le emerge @all-installed ça va te mettre à jour même ce qui n'est plus en dépendance de que t'as d'installé et qui partirai dans un depclean ensuite, donc ça fait de la compilation inutile ;p

----------

## GentooUser@Clubic

Ça fait des mois que j'utilise les pré-versions de portage 2.2 et je savait rien de tout ça moi.

C'est décidé je m'offre un petit Core 2 Quad Q6600 avant Noël   :Very Happy: 

----------

## kopp

La plupart des choses sont arrivées il y a un mois tout au plus (pour les sets) et la semaine dernière pour --jobs etc.

En tous cas, on en parle pas depuis plus longtemps.

Du coup, tu n'as pas laissé les choses passer à côté pendant bien longtemps si ça peut te rassurer.

Sinon, c'est vrai qu'on est pas toujours bien au courant de ce qui arrive dans portage.

Peut-être qu'avoir des infos à la fin de l'ebuild sur les nouvelles fonctionnalités, ça pourrait être pas mal.

(à moins que ça y soit déjà et que je ne fasse vraiment pas gaffe)

----------

## xaviermiller

planet Gentoo (ou Gentoo Universe) en parle pas mal aussi  :Wink: 

----------

## d2_racing

En effet, le planet semble être une bonne source d'information.

----------

## kopp

Oui, mais ça oblige à suivre le planet, ce que tout le monde ne fait pas.

----------

## xaviermiller

avec un bon lecteur de flux RSS, ce n'est pas trop contraignant  :Wink: 

(j'utilise le plug-in Sage pour FF  :Smile: )

----------

## Dismantr

j'avais cru comprendre, lors d'un précédent post (va falloir que je recherche ça) que les commandes :

emerge -vautND system

emerge -vautND world

emerge --depclean

revdep-rebuild                          (autant de fois que nécessaire)

étaient la combinaison la plus disons, recommandée, pour faire les choses correctement...

Aurais-je mal compris ?

----------

## GentooUser@Clubic

C'est a peu près ce que je fait depuis le début:

```
emerge -avuND world (@system @world maintenant)

emerge --ask depclean

revdep-rebuild -- --ask
```

----------

