# [tip] boot (vraiment) plus rapide

## Enlight

Bon, je voulais faire une installe fraiche (changer la table des partitions, changer de FS) et donc là c'est un simple stage 3 sans la moindre optimisation que j'ai!

Donc après les fly with gentoo (pas fait encore sur cette install) et cie, je viens d'enlever 10 secondes à mon boot en réemergeant baselayout et bison (le parseur de fichiers de config) avec le use flag "static".

Bref, ça devrait faire plaisir aux heureux possesseurs de laptops, et ça pourrait aider à convertir du windowsien pour qui le temps de boot reflète l'ensemble des perfs d'une machine  :Twisted Evil:  ...

ps :Je penche pour 90%de gain en provenance de bison

valà, maintenant je prie pour pas avoir 95% de gens qui vont me dire "ben tu découvres mon pauvre??!!!" et j'envoie.

----------

## Tony Clifton

c'est bon à savoir, j'essayerais ça sur ma prochaine install (j'attends la 2005.0 et kde-3.4).

Juste une petite précision faut pas activer ce flag pendant la création du bootstrap.

----------

## Enlight

+1 pour ne pas activer pendant la création du bootstrap, mais y'a t'il vraiment encore des gens qui font l'erreur (à mon sens) dde faire un stage 1???

----------

## manu.acl

Recompil en cours chez moi via ssh  :Very Happy: 

----------

## Tony Clifton

 *Enlight wrote:*   

> mais y'a t'il vraiment encore des gens qui font l'erreur (à mon sens) dde faire un stage 1???

 

moi j'aime bien le stage 1, en plus ça permet d'avoir un système bien à jour.

----------

## Enlight

Le stage 1 over stage 3 te permets d'être plus a jour et sur le long terme, car lors des stages1 certains paquets ne sont pas inscrit dans le world (confirmé par Marius (genone) Mauch, mais il y'a un fix) et en conséquence ne sont plus jamais actualisés. De plus si tu veux GCC 3.4.3, il est totalement inutile de se compiler boostrap et système 2 fois.

----------

## Adrien

Merci pour ce tip Enlight, ça fera pas de mal d'avoir un boot plus rapide (surtout sur mon Celeron 466). Je vais essayer ça dès ce soir!  :Very Happy: 

----------

## Polo

 *Enlight wrote:*   

> Le stage 1 over stage 3 te permets d'être plus a jour et sur le long terme, car lors des stages1 certains paquets ne sont pas inscrit dans le world (confirmé par Marius (genone) Mauch, mais il y'a un fix) et en conséquence ne sont plus jamais actualisés. De plus si tu veux GCC 3.4.3, il est totalement inutile de se compiler boostrap et système 2 fois.

 

ben merci pour le tip, mais moi j'ai fait un stage 1 et j'ai gcc 3.4.3 (sans pour autant compiler mon systeme deux fois)

 :Arrow:  faire le bootstrap

 :Arrow:  emerger gcc 3.4.3

 :Arrow:  emerge system

 :Arrow:  emerge world

et roulez jeunesse... ca a marché nickel  :Wink: 

----------

## Enlight

ça fait toujours 2 compiles du bootstrap, et il faut compiler gcc 2 fois pour avoir gcc 3.4.3 (et binutils + pour être sûr glibc) buildés avec gcc 3.4.3

----------

## Polo

oui c'est pas faux, mais ce n'est pas *tout* le système....

pour avoir mon Cflag -march=pentium-m , je me suis dit que compiler 2 fois le bootstrap et gcc valait le coup

----------

## Tony Clifton

Concrètement quelle différence apporte l'utilisation du flag static ?

c'est un peu comme du prelink ?

----------

## Enlight

Je veux oas dire de conneries mais il me semble que c'est plus que du prelink et que les libs ne sont plus dynamiques, donc en gros ça reviendrait à les avoir directement dans le binaire. ça bouffe un peu de ram mais bon... c'est pas la mort non plus. Dès que j'aurais mes 2 * 512, je passe static dans les use du make .conf.

----------

## Tony Clifton

ok, de toutes façon avec 512, on peut pas dire que linux consomme beaucoup de ram alors autant les utiser un peu

----------

## zdra

Pour accelerer le boot je trouves qu'il faudrait un systeme pour lancer tt les services en parallele. Je sais qu'il y a une option dans je sais plus quel fichier, mais ça marche pas ché moi. Je crois qu'on peut gagner beaucoup de temps en lancant X le plus vite possible et charger les autres services en meme temps. Mais moi meme si je mets X dans le runlevel boot, il démare qd meme que tout à la fin. De plus des services comme dhcp prennent du temps innactif qu'il faudrait récuperer en chargant d'autres services en parallele.

Qqn a de l'info pour ça ? est-ce possible déjà, est-ce que ça marche ?

----------

## Adrien

 *zdra wrote:*   

> Pour accelerer le boot je trouves qu'il faudrait un systeme pour lancer tt les services en parallele. Je sais qu'il y a une option dans je sais plus quel fichier, mais ça marche pas ché moi.

 

Pour le fichier il me semble que c'est une option dans /etc/conf.d/rc .

Une option du genre RC_PARALLEL_STARTUP  :Wink: 

Pas encore essayé  :Rolling Eyes: 

----------

## zdra

En effet c'est ça... j'ai essayé... j'ai pas vu de changement...

----------

## Dais

Faut dire que certains services se doivent d'être lancés avant d'autres malgré tout. Tu ne pourras jamais tous les lancer en même temps (enfin je crois que si, mais ça te causera des erreurs)

----------

## Enlight

Pour le parralèle startup, il faut en plus tweaker certains init.d cf le how to de saigneur (je crois) ou le topic flying with gentoo

----------

## Faust_

 *Enlight wrote:*   

> car lors des stages1 certains paquets ne sont pas inscrit dans le world (confirmé par Marius (genone) Mauch, mais il y'a un fix) et en conséquence ne sont plus jamais actualisés.

 

salut

je n'etais pas au courant de ce truc et je ne trouve pas d'info dessus, c'est quoi le fix et on le trouve ou ?

merci

edit: en fait c'est bon question a oublier, merci quand meme  :Smile: Last edited by Faust_ on Fri Mar 04, 2005 2:33 pm; edited 1 time in total

----------

## Gentoo_Lover

bonjour tout le monde , moi perso je suis passé en reiser4 (stage 1 avec gcc 3.3.5 x86) et au final j'ai un boot qui dure moins de 15s  :Very Happy: (je n'ai pas chronométré mais à peu prés...), sinon pour améliorer le boot il y a aussi tuning gentoo (qui a l'air pas mal au niveau du boot) :Wink: 

----------

## Enlight

comme dit dans mon premier post, je suis sur une isntall toute fraiche, sans aucun autre tweak et mon boot vient de passer de 24 à environ 12 secondes. Enclair le temps de tweaker le boot et de passer en reiserfs 4 (dois faire mon live cd cause besoin ndiswrapper) et ça va ch... ensuite je tenterais (dès que j'ai mes 2 fois 512 de ram) le lancement des librairies (et qques binaires peut être) en initrd (genre firefox qui s'ouvre en 0.01 s :Wink:  )Last edited by Enlight on Fri Mar 04, 2005 1:37 pm; edited 1 time in total

----------

## Trevoke

Ooh joli...

----------

## manu.acl

 *Enlight wrote:*   

> Dès que j'aurais mes 2 * 512, je passe static dans les use du make .conf.

 

C'est déconseillé, par exemple avec xorg tu ne pourras pas ajouter tes propres drivers 3d. (expérience perso)

----------

## Dais

Dais ce cas, mettre -static pour xorg-x11 dans le package.use  :Razz: 

À moins qu'il y ait d'autres packages problématiques ?

----------

## manu.acl

A étudier  :Rolling Eyes: 

----------

## Enlight

yep! Manu t'as déjà pu tester? Quelqu'un d'autre sinon? j'aimerai bien quelques retours avant-après selon les configs, les fs etc...

----------

## Tony Clifton

Il faut donc l'utiliser uniquement avec le "emerge system" (ou "emerge -u system") ?

----------

## Enlight

Non! emerge system refait une partie du bootstrap! (mais pas la glibc a priori)

bash-2.05b# emerge -p system

 *Quote:*   

> These are the packages that I would merge, in order:
> 
> Calculating system dependencies ...done!
> 
> [ebuild     U ] app-arch/bzip2-1.0.2-r5 [1.0.2-r3] 
> ...

 

----------

## billiob

Je viens de re-emerger baselayout et bison avec le flag static et je n'ai pas constaté de différence. Il n'y a pas de changements d'après bootchart non plus.

Il faut bien faire 

```
USE="static" emerge baselayout bison

```

 ?

----------

## Trevoke

Je vois pas l'interet de rebooter pour essayer lol desole  :Wink: 

----------

## Enlight

 *billiob wrote:*   

> Je viens de re-emerger baselayout et bison avec le flag static et je n'ai pas constaté de différence. Il n'y a pas de changements d'après bootchart non plus.
> 
> Il faut bien faire 
> 
> ```
> ...

 

 :Shocked:   Je suis surpris là! tu n'utilise pas d'initrd pour charger certaines libs ou certains programmes au boot? Et surtout tu es sûr que tu n'utilisais pas ce flag avant? Tu as déjà fait quoi comme optimisations et en combien de temps tu bootes?

----------

## manu.acl

J'ai pas chronomètré le temps que mettait mon ordi à booter avant ça mais maintenant il met 30s entre le moment où j'appuye sur [POWER] j'usqu'à avoir entrance d'affiché.

----------

## billiob

@Trevoke: je n'ai pas rebouté que pour ça, ma soeur avait besoin d'aller sous windows !

@Enlight: mon initrd ne me sert que pour le bootsplash.

Que faire pour ajouter à l'initrd des libs ou des programmes ?

Sinon, au passage, je viens de constater que etcat -u bison ne fonctionnait pas et ne marche pas non plus pour d'autres paquets, mais les autres fonctions marchent correctement. 

EDIT: c'est normal, il faut utiliser equery à la place.

----------

## guilc

Hum, je ne vois pas bien en quoi le linkage statique permettrai de gagner 10s sur le boot, quelques dixiemes, ok, mais pas plus...

Et je vois un GROS probleme a ce linkage statique : imagine qu'une librairie utilisée s'avere avoir des failles de sécurité, ben tu est OBLIGÉ  de penser a recompliler les programmes linkés en statique, et donc, il faut savoir exactement sur quelles librairies le programme est linké aussi... Bref, pas très pratique tout ça...

----------

## sireyessire

 *guilc wrote:*   

> Hum, je ne vois pas bien en quoi le linkage statique permettrai de gagner 10s sur le boot, quelques dixiemes, ok, mais pas plus...
> 
> Et je vois un GROS probleme a ce linkage statique : imagine qu'une librairie utilisée s'avere avoir des failles de sécurité, ben tu est OBLIGÉ  de penser a recompliler les programmes linkés en statique, et donc, il faut savoir exactement sur quelles librairies le programme est linké aussi... Bref, pas très pratique tout ça...

 

+1

----------

## Enlight

C'est jouable ça d'exploiter une éventuelle faille de bison ou de baselayout??? Pour ceux qui gagnent très peu, étaient-ils prelinkés avant???

billibob : https://forums.gentoo.org/viewtopic-t-296892.html

----------

## Enlight

bon ben désolé, mais je reviens de tester (juste pour bison pas pour baselayout), ben sans le static c'est 17 s de boot, avec 13 pour être exact.

----------

## Adrien

Ben moi j'ai essayé et.....ça marche pô  :Sad: 

----------

## Enlight

heu moi je compte à partir du moment ou j appuyes sur entrée dans grub! ceux qui sentent rien, vous avez le prelink ou les LDFLAGS?

----------

## billiob

Moi j'ai le prelink mais pas les LDFLAGS. En fait, bootchart m'indique que j'ai gagné 3 secondes : de 38 à 35s. 

[OFF] Sinon, mettre des libs et des bins (genre bash, gawk, mount, gzip, grep, modprobe, find ...) dans un initrd, ça accélère vraiment le démarrage et le lancement des applis ? [/OFF]

----------

## Adrien

 *Enlight wrote:*   

> heu moi je compte à partir du moment ou j appuyes sur entrée dans grub! ceux qui sentent rien, vous avez le prelink ou les LDFLAGS?

 

Ben,ici, pas de prelink ni de LDFLAGS dans mon make.conf en tout cas...

----------

## Enlight

billibob, bon ben 3 secondes c'est pas dégueu sur un boot. je pense que la différence est moins flagrante que chez moi car tu utilisais déjà prelink.

Pour ce qui est du chargement des libs en binaire, j'ai pas essayé car il faudrait que je change mon partitionnement (donc je vais me faire un tar de ma config et je verrais ensuite en mêm temps que reiser4. Par contre ça ralenti forcément le boot puisqu'il faut loader les libs et/ou binaires en ram, par contre après, un firefox qui s'ouvre en 0.01 s je trouve ça assez terrible.

@ Adrien, j'ai aussi remarqué qu'une compile bison en -O3 -funroll-loops  me faisait tout reperdre niveau temps de boot.

----------

## Adrien

 *Enlight wrote:*   

> 
> 
> @ Adrien, j'ai aussi remarqué qu'une compile bison en -O3 -funroll-loops  me faisait tout reperdre niveau temps de boot.

 

Je n'ai plus les flags -funroll-loops, ni -03 d'ailleurs !

N'empêche, je serais bien curieux de savoir d'où ça vient ton gain de temps...ça me brancherait bien que ça boote un peu plus vite.

je testerai peut-être le howto flyin' with gentoo un de ces 4, qui sait

----------

## kwenspc

L'option -funroll-loops est à éviter de toutes façons. je l'ai mise sur 

mon premier système et à la première mise à jour je l'ai enlevé. J'ai tout de suite vu la différence pour presque tout mes programmes et notemment les plus lourd : un gain de rapidité non négligeable!

à éviter donc.

----------

## sireyessire

 *kwenspc wrote:*   

> L'option -funroll-loops est à éviter de toutes façons. je l'ai mise sur 
> 
> mon premier système et à la première mise à jour je l'ai enlevé. J'ai tout de suite vu la différence pour presque tout mes programmes et notemment les plus lourd : un gain de rapidité non négligeable!
> 
> à éviter donc.

 

c'est étonnant ça!

Attention à la confusion:

l'option -funroll-loops te permet au contraire de rendre tes programmes plus rapides en évitant les branch link:

tes boucles for sont dépliées pour avoir du code séquentiel plus rapide car tu as pas de flush à faire pour le pipe du processeur. D'où une rapidité evidente!

par contre le fait de déplier des boucles gènère un code beaucoup plus gros et donc malheureusement plus long à charger(c'est pour ça que tu étais pas ravi)

En conclusion, le -funroll-loops ne rend pas le programme plus lent mais plus rapide dans son exécution, simplement le chargement du programme ( en mémoire) est plus long (mais tu le fais qu'une fois) donc c'est déconseillé si tu veux juste exécuter tes programmes plein de fois pendant pas longtemps mais c'est très utile si c'est pour un programme qui est chargé une fois et qui va s'exécuter beaucoup (server..)

voilà, c'est pourquoi en général pour un desktop tu mets jamais -O3 (qui contient le -funroll-loops)

----------

## Enlight

c'est pour ça que chez moi le funroll loop ira de paire avec ça : https://forums.gentoo.org/viewtopic-t-296892.html ça rique d'être mortel au boot mais ensuite...(vivement le giga de ram)

----------

## zdra

à noter qu'un binaire plus gros résulte en une execution plus lente. Le compromis vitesse/taille est une chose vraiment pas trivial. En effet un code compacte rentre plus facilement dans la cache du processeur, et donc beaucoup plus rapide d'execution.

----------

## ppierre

 *Enlight wrote:*   

> https://forums.gentoo.org/viewtopic-t-296892.html ça rique d'être mortel au boot mais ensuite...(vivement le giga de ram)

 

Un peut moins violent que de tout mettre dans un ramdisk : pré-charger les fichiers utilisés lors du boot.

J'ai fait un essai, en utilisant les temps de derniers accès des fichiers (donc en enlevant l'option noatime du fstab).

Pour trouver les fichiers :

/root/trouve_boot

```
#!/bin/bash

temps=$(echo `(cat /proc/uptime | cut -d " " -f 1 )`/60 | bc)

find / -amin -${temps} -cmin +${temps} -xtype f -xdev -printf "%A@ %p\n" | sort -n | cut -d " " -f 2 > boot_list
```

rq: ajouter vos points de montage à la fonction find du fait de l'option -xdev (find / /var /tmp ...)

Pour les pré-charger, j'ai ajouté cette ligne à la fin de la fonction start de /etc/init.d/localmount

```
nohup cat /root/boot_list | xargs --replace cp {} /dev/null &> /dev/null &
```

Cela ne permet pas de booter plus rapidement, mais si on lance le script après avoir utilisé les applications courante, celles-ci devraient se lancer plus rapidement au prochain démarrage.

Ps: penser à remettre noatime

----------

## Enlight

 *zdra wrote:*   

> à noter qu'un binaire plus gros résulte en une execution plus lente. Le compromis vitesse/taille est une chose vraiment pas trivial. En effet un code compacte rentre plus facilement dans la cache du processeur, et donc beaucoup plus rapide d'execution.

 

suis pas convaincu (d'ailleurs plus j'y réfléchis moins ça me semble probable.), les cache L1 ne sont que des registres d'adresse et de données et les L2 varient énormément d'un proc à l'autre, perso j'ai 512 ko et je pense que peu de programmes tiennent là dedans. je pense qu'un funroll loop ne peut que plomber le chargement de l'application mais pas sont fonctionnement vu qu'il ne fait en fait que supprimer des tests conditionnels.

pour ton proc, ce qui compte ce n'est pas la taille du binaire, mais le nombre d'instructions à effectuer. avec une boucle, là même partie du code peut être chargée en cache plusieures fois d'affilée alors qu'en déroulant la boucle, ça n'aurait peut être pas été nécessaire (du moins pas autant de fois.)

Par contre si quelqu'un peut me dire comment funroll-loop procède avec les boucles type pour i de 1 à N avec N non prédéterminé je suis preneur.

----------

## kwenspc

désolé je me suis mal exprimé : avec l'option -funroll-loops mes programmes étaient beaucoup plus lourd à charger

C'était sur une machine avec de l'udma 33 et j'ai vraiment vu la différence quand j'ai viré cette option (j'ai toujours mis -O2 sinon)

Par contre (et ça je le savais pas) je suis en -O3 sur ma nouvelle machine ce qui implique donc que j'ai l'option -funroll-loops d'activé d'office (c'est ça sireyessire?). Mais bon vu que c'est une bécane plutôt costaude je vais sans doute pas voir grand chose comme différence que ça soit au chargement ou à l'exécution non?

Bon en tout cas pour ma vieille machine j'ai trouvé la solution : elle est toujours allumée  :Very Happy:  (serveur) donc ça doit faire plus de 2 mois que je ne l'ai pas rebooté. (quoique je devrais le faire pour mettre un nouveau kernel)

----------

## kopp

 *zdra wrote:*   

> Pour accelerer le boot je trouves qu'il faudrait un systeme pour lancer tt les services en parallele. Je sais qu'il y a une option dans je sais plus quel fichier, mais ça marche pas ché moi. Je crois qu'on peut gagner beaucoup de temps en lancant X le plus vite possible et charger les autres services en meme temps. Mais moi meme si je mets X dans le runlevel boot, il démare qd meme que tout à la fin. De plus des services comme dhcp prennent du temps innactif qu'il faudrait récuperer en chargant d'autres services en parallele.
> 
> Qqn a de l'info pour ça ? est-ce possible déjà, est-ce que ça marche ?

 

euh on en a déjà discuté, et en fait cest que le script attend que les tty soient lancés, donc suffit de modifié le script comme suit :

 *Quote:*   

>  Code:
> 
> start() {
> 
>         setup_dm
> ...

 

https://forums.gentoo.org/viewtopic-t-295718-highlight-.html

ps: ouais je sais je suis off mais bon ....

----------

## LostControl

 *Enlight wrote:*   

>  *billiob wrote:*   Je viens de re-emerger baselayout et bison avec le flag static et je n'ai pas constaté de différence. Il n'y a pas de changements d'après bootchart non plus.
> 
> Il faut bien faire 
> 
> ```
> ...

 

J'ai aussi voulu tester. J'ai recompilé bison avec "static". Pour vérifier, j'ai fait un "file" sur l'exécutable après et toujours "dynamically linked"  :Shocked:  J'ai recompilé avec et sans "static" pour comparer les 2 binaires. Résultat : les binaires sont les mêmes  :Confused:  Un "grep" lors de la compilation ne fait rien resortir !!! LDFLAGS ne semble pas passer au linker  :Confused: 

Bizarre tout ça... Quelqu'un peu confirmer ?

----------

## sireyessire

 *kwenspc wrote:*   

> désolé je me suis mal exprimé : avec l'option -funroll-loops mes programmes étaient beaucoup plus lourd à charger
> 
> C'était sur une machine avec de l'udma 33 et j'ai vraiment vu la différence quand j'ai viré cette option (j'ai toujours mis -O2 sinon)
> 
> Par contre (et ça je le savais pas) je suis en -O3 sur ma nouvelle machine ce qui implique donc que j'ai l'option -funroll-loops d'activé d'office (c'est ça sireyessire?). 

 

oups désolé, ai confondu 2 options (avec -finline-functions, qui a le même genre de comportement: virer les appels de fonctions et copier le code de la fonction ) , non le funroll-loops est pas activé par -O3:

 *Quote:*   

> -funroll-loops
> 
>     Unroll loops whose number of iterations can be determined at compile time or upon entry to the loop. -funroll-loops implies both -fstrength-reduce and -frerun-cse-after-loop. This option makes code larger, and may or may not make it run faster.
> 
> -funroll-all-loops
> ...

 

donc t'inquiète pas  :Wink:  mais tu peux le mettre si tu veux  :Laughing: 

----------

