- Support des CPU multicoeurs Niagara de Sun
- Support du chipset wifi Broadcom 43xx utilisé dans les portables (en particulier l'Airport Extreme dans les iBook/Powerbook)
- L'optimisation de l'image du noyau au démarrage sur les x86 : en fonction de l'architecture processeur sur lequel il doit s'exécuter, le noyau remplacera une partie de son binaire par des macros assembleur optimisées. Le but d'étant d'avoir qu'une seule image pour toutes les variantes de x86 et non des images pour 386,486,586,686,k7,...
- Un nouvel ordonnanceur optimisé pour les processeurs multicoeurs.
- splice(), un nouvel appel système qui envoie des données entre deux descripteurs de fichiers.
- sync_file_range(), un nouvel appel système permettant de mieux contrôler le moment où les données modifiées dans les fichiers sont écrites physiquement.
- Le support du protocole H.323 (utilisé en audio et visioconférence) dans iptables
- Des corrections de bogues...
![[en]](../images/en.png)
L'annonce officielle sur la LKML (498 hits)-
Le changelog simplifié (1073 hits)
-
Le changelog complet (426 hits)
-
Les nouveaux appels système (425 hits)
-
L'optimisation de l'image du noyau au démarrage (966 hits)
> Lire la dépêche (146 commentaires, moyenne: 3).
Vous avez demandé le commentaire #725192.
Run by 
Cette page a été générée par Templeet en 0.1174s (dont 0.0117 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
"L'optimisation de l'image du noyau au démarrage"
Cela serait pas mal si il pouvait optimiser aussi la detection de materiel au début pour booter plus vite. Par exemple, en commençant la déctection par les periphériques qui étaient déjà là avant. Tout ça dans le but de démarrer plus vite.
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Ca ne serait pas plutôt le rôle de hotplug/udev ?
Voici donc comment meurt la liberté, sous un tonnerre d'applaudissements...
[^]Re: "L'optimisation de l'image du noyau au démarrage"
ben je ne sais pas trop. Mais quand tu regardes les logs du kernel (le haut de dmesg) tu vois plein de "découverte" de périphérique. Or, cela prends une part du temps total non négligeable (sans la partie "rc", le boot purement kernel doit prendre entre 10 et 20 secondes).
[^]Re: "L'optimisation de l'image du noyau au démarrage"
"Votre configuration a changé, vous devez redémarrer..."
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Pour démarrer le kernel a besoin seulement d'une partie du matériel, donc à priori le reboot ne devrait pas arriver trop souvent.
Aussi pour éviter le reboot il est possible de d'avoir deux entrées dans le bootloader: une par défaut qui réutilise la configuration existante, une autre qui fait le full discover.
Ceci dit avant d'en arriver la, il y a, a mon avis, *plein* d'optimisation à faire: BeOS sur un Celeron 333(128Mo de RAM) mettait 14s pour aller jusqu'à un bureau (fonctionnel pas comme celui de Windows qui triche).
Sous Linux, les 14s représentent en équivalent: le boot du kernel + le démarrage de KDE ou Gnome en auto-login.. Et BeOS le fournissait sans qu'on ait à trifouiller le kernel ou autre.
On es loin du compte à l'heure actuelle sur des machines bien plus puissantes..
Si les dev de BeOS l'ont fait, ce n'est pas la magie, c'est reproductible, mais bon souvent les utilisateurs Linux sont d'une mauvaise foi rare: "pas besoin d'arreter un PC sous Linux", ben voyons! Mon ordinateur n'est pas très bruyant mais mon appart est tout petit et j'aime dormir la nuit..
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Une machine moderne sous Linux lance bien plus de services que BeOS. Ma machine principale a en ce moment 3 disques de 160, 160 et 80Go, c'est plus long à tester et à monter que le seul disque de 800 Mo que l'on avait à l'époque. Les périphériques USB, les cartes TV et des tas d'autres accessoires sont apparus depuis l'heure de gloire de BeOS.
Sur Mandriva Cooker, une importante optimisation du boot a été proposée (par un grenoblois si ma mémoire est bonne) et elle donne de très bons résultats. Son nom est pinit comme parallèle initialisation. Cette technique qui sera intégrée dans la Mandriva 2007 utilise un système de dépendance des services. Exemple : NFS et Samba nécessitent que le réseau soit initialisé. Il en résulte un gain de 20% par rapport à une Mandriva 2006, elle-même bien plus rapide que la Mandriva 2005.
Si on veut aller encore plus vite, il faudra tricher comme Windows XP.
[^]Re: "L'optimisation de l'image du noyau au démarrage"
>Ma machine principale a en ce moment 3 disques de 160, 160 et 80Go, c'est plus long à tester et à monter que le seul disque de 800 Mo que l'on avait à l'époque.
Mmm, ce que teste le kernel c'est les filesystem pas les disques dans leur intégralité et puis il pourrait/devrait le faire en parallèle (j'ignore si le kernel le fait a l'heure actuel).
>Les périphériques USB, les cartes TV et des tas d'autres accessoires sont apparus depuis l'heure de gloire de BeOS.
Les periphériques USB oui, les cartes TV non, par contre elle n'était probablement pas supporté par BeOS à l'époque.
Ceci dit, si tu boote depuis un disque, l'énumération des périphériques USB n'est pas "critique": tu peux la faire tard dans le processus de boot, maintenant je ne sais pas si ça aide..
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Pour l'initialisation de l'usb tout dépend des cas, dans certains tu ne peux carrément pas t'en passer...
Preuve par l'exemple :
Tu as ton /home sur un dd usb externe...
D'autre part, en ce moment sur cooker, ça parle de faire du préchargement de fichier en regardant les accès fichiers au boot via strace et ensuite les précharger au prochain boot...
Aucune idée du niveau d'implémentation (il me semble que ce n'est qu'une idée...)
Mais en tout cas c'est une bonne idée, quand au boot du pc, honnêtement ça reste raisonnable, sur mon pc (cooker 2007) ça boot en 35-45secondes
(tout dépend du fait que je tape vite ou non les pass d'accès a mes partition chiffrées...)
Bref, l'optimisation d'une distribution c'est vraiment complexe, tu a des configurations complètement différentes (desktop/server eco-recup monté a la mano), ou qui ne changent presque jamais (laptop), bref ça avance, mais on y sera bientôt...
Sinon j'ai testé le suspend2 (avec du apache/php5/mysql/named/etc) et le temps de boot est exceptionnel.
Bon je vous arrête tout de suite, ma saleté de carte graphique nvidia (fx5700) avec le drv proprio se relance pas, donc reset du service dm obligatoire :'(
Bref, si on sait ce qu'on veux on peux vraiment accélérer le boot, suffit d'y mettre les moyens et un matériel adapté...
site perso : http://rapsys.free.fr/
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Il y avait pas un genre de système un peu dans l'esprit sous windows, genre l'arrangement des fichiers pour les applis les plus utilisés démarrent plus vite ? j'imagine qu'ils s'arrangaient pour tout placer sur des secteurs de disques consécutifs ... (cela dit c'est un très vague et très approximatif souvenir)
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Oui, il te proposait l'option avant de lancer l'outil de défragmentation.
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Il y a initng qui permet de faire ça, c'est censé remplacer le init actuel.
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Sur Mandriva Cooker, une importante optimisation du boot a été proposée (par un grenoblois si ma mémoire est bonne) et elle donne de très bons résultats. Son nom est pinit comme parallèle initialisation. Cette technique qui sera intégrée dans la Mandriva 2007 utilise un système de dépendance des services.
Si on veut aller encore plus vite, il faudra tricher comme Windows XP.
T'es un gros rigolo, le truc qui fait que XP boote vite, c'est exactement cette technique(plus le profiling des acces disques durant le boot)
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Tu es un rigolo encore plus gros alors, parce que la triche dont il parle, c'est le fait que, malgré les soit-disant techniques qu'implémente Windows XP comme tu dis, il lui faut toujours pas mal de temps (au moins une minute chez moi) après le login pour devenir opérationnel.
Résultat, sur toutes mes machines (sauf le Thinkpad où j'ai pas pu tester), Windows XP SP2 "boote" beaucoup moins vite que mon Linux.
Mon Linux custom utilise simpleinit-msg (qui fait la parallélisation depuis belle lurette) mais aucun profiling, et lance plein de services utiles au boot (ftp, ldap, ssh, cups, ...), contrairement au Windows XP.
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Tu es un rigolo encore plus gros alors, parce que la triche dont il parle, c'est le fait que, malgré les soit-disant techniques qu'implémente Windows XP comme tu dis, il lui faut toujours pas mal de temps (au moins une minute chez moi) après le login pour devenir opérationnel.
C'est plutot que tu n'as pas compris comment ca fonctionne.
Les services demarrent en parralele, donc meme apres le login il y a encore des services qui demarrent ou qui sont en train de demarrer.
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Si il a très bien compris que le boot est loin d'être fini quand l'interface graphique est présenté.
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Seulement BeOS, il ne démarrait pas sur ma bécane. Il restait bloqué après 2 secondes de démarrage et puis plus rien. Linux, lui fonctionnait (et fonctionne toujours).
Question mauvaise foi, comparer un OS qui fonctionne sur quelques configurations avec un OS qui peut tout faire et sur n'importe quelle machine, c'est pas mal non plus...
DOS+Windows 3.1 démarrait en 30 secondes sur mon 286! Ce doit être un meilleur OS que Linux alors :)
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Si tu veux aller par la Windows est le meilleur car tout le matériel est supporté.
BeOS supportait moins de matériels que Linux certes, mais c'était quand même un OS 'multi-configuration': pas figé à un matériel spécifique..
Et comme Linux aujourd'hui, il fallait faire attention quand on achetait son matériel..
La vitesse de démarrage n'est certes pas le seul critère de comparaison, mais BeOS était un OS assez comparable à Linux du point de vue desktop: protection mémoire, multi-threading, SMP, hardware supporté relativement vaste etc..
Et les applications (assez peu nombreuses malheureusement) étaient bien plus réactives que sous Linux (meilleure utilisation du multi-threading je pense), ce qui est *très* agrèable a utiliser..
Maintenant BeOS est mort, reste Linux qui s'amélliore lentement mais surement..
Sur certains points Linux était déja en avance à l'époque (multi-utilisateurs, export d'écrans) sur d'autres: vitesse de boot, réactivité des applications, Linux reste en retard (malgrès les CPU actuel biens plus puissants) mais les disques dur avec flash incorporé devraient s'occuper de la vitesse de boot et les processeur multi-core fourniront une légère ammélioration coté réactivité et on peut l'espèré inciteront peut-etre dans le future à une meilleure utilisation du multi-threading dans le codage des applications..
[^]Re: "L'optimisation de l'image du noyau au démarrage"
BeOS avait aussi ses lacunes, et on l'oublie souvent, préférant se cacher derrière le côté nostalgique. Il n'était pas multi-user par exemple.
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Euh, si tu relies mon post, tu verras que je l'avais marqué..
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Si tu veux aller par la Windows est le meilleur car tout le matériel est supporté
Ben non ça marche pas non plus alors.
Va donc dire à mon vieux scanner SCSI mustek que Windows supporte tous les périphériques. Même son constructeur n'a pas l'air d'être au courant et conseille d'en acheter un autre. Idem pour ma vieille carte TV (dont les logiciels et codecs ne fonctionnent même plus sous WinXP) et mon adaptateur de manette console sur port série.
De plus, la vitesse de boot est plus dépendante de ton matériel, de la façon dont ton kernel est compilé et les options activées.
Par exemple, sur mon linux familial qui est un bipro avec des disques SCSI, le boot du kernel seul (et même le boot complet) est plus long que sur mon petit barebone avec un Athlon XP et des disques ATA.
Les disques SCSI et le bi pro demandent plsu de validation, mais ensuite, tout va plus vite que sur le barebone.
En revanche la réactivité des applis n'a rien à voir avec le kernel, ou très peu.
[^]Re: "L'optimisation de l'image du noyau au démarrage"
En compilant le noyau avec juste ce qu'il faut de drivers ca doit aider, je pense
[^]Re: "L'optimisation de l'image du noyau au démarrage"
une idée interessante serait un truc qui permettent de detecter tout le materiel et de le configurer avec juste ce qu'il faut. Je sais pas vous mais moi la doc utilisateur (la documentation technique n'existe pas apparement) de mon ordi Medion en Allemand, c'est pas ce que je prefere lire.
[^]Re: "L'optimisation de l'image du noyau au démarrage"
c'est le boulot de udev, qui le fait d'ailleurs plutôt pas mal je trouve.
Et puis à part le depmod (qui sera d'ailleurs enlevé au boot de debian bientôt si j'ai bien suivi), je ne pense pas que le nombre de modules chargeables impacte les performances (à part éventuellement le déplacement des têtes du disque entre les 2 modules à charger :).
Une proposition de script de génération de .config en fonction du matériel était passée sur la lkml (et relayée sur linuxfr, mais je ne retrouve pas la page). Les développeurs avaient expliqué que si on ressentait le besoin d'un tel script, il fallait mieux utiliser les noyaux compilés des distribs avec les outils chargés de charger les bons modules (hotplug puis udev).
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Ce script, je me suis déjà demandé pourquoi il n'existait pas encore. On pourrait lui fournir un paramétrage "haut niveau" : machine de bureau | serveur | calculateur, préférence rapidité ou réactivité, ...
Concernant la réponse des dev :
- le noyaux compilés sont généralistes : ils répondent donc mal aux besoins de l'utilisateur
- selon le type d'utilisation, il vaut mieux compiler en module ou pas
- il faudrait compiler tous les modules au cas où
Avec tous les experts-compilation qu'on a sous la main, on devrait arriver à des règles usuelles pour construire un bon .config avec quelques informations de haut niveau, non ?
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Une proposition de script de génération de .config en fonction du matériel était passée sur la lkml (et relayée sur linuxfr, mais je ne retrouve pas la page).
retrouvé :
http://lkml.org/lkml/2005/9/14/379
[^]Re: "L'optimisation de l'image du noyau au démarrage"
euh ... bon ... je vais peut-être aller à l'encontre d'un vent nouveau venu d'ailleurs, mais à part jouer à c'est moi qui ait la plus grosse ca sert à quoi de gagner 3 secondes sur un boot ?
à part attendre 3 secondes de moins bien entendu ... cette discussion réccurente n'a pour moi aucun intérêt et ne nécessite pas toute la perte de temps qu'elle occasionne dans des débats réccurents avec un argumentaire toujours identique ... (je crois qu'on doit avoir compris que je pense qu'on tourne en rond ! :) )
Vous ne voulez pas rebooter ... mettez votre machine en veille avec l'acpi et vous irez 100 fois plus vite que de bidouiller les inits et autres services ...
travailler sur l'acpi ... ca ca ferait avancer le smilblick !
[^]Re: "L'optimisation de l'image du noyau au démarrage"
mais à part jouer à c'est moi qui ait la plus grosse ca sert à quoi de gagner 3 secondes sur un boot ?
Dans le cadre d'une application embarquée sur base de noyau Linux, cela permet d'éviter de sucer la batterie avec une veille ou d'implémenter un système "compliqué" soit à base de (S)RAM rafraîchie pour maintenir le système dans un état donné une fois le processeur "arrêté".
Je suis en ce moment en train de bosser sur une telle appli' embarquée, et l'application doit être économe en courant ET répondre rapidement à un évènement extérieur.
Dans ce genre d'application embarquée, la première chose qu'on fait, c'est réduire le noyau au maximum, avec seulement les périphériques utiles et les démons vitaux, mais cela n'est pas toujours chose aisée, car les pilotes sont parfois écrits d'une certaine manière qui oblige à compiler le support pour 30 périphériques dérivés d'un contrôleur alors qu'un seul nous intéresse, et par là-même impose la détection de ces 30 possibilités au démarrage.
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Sans avoir besoin de chercher des exemples dans l'embarqué,
c'est un confort extrême d'avoir un PC qui boot rapidement.
Un PC allumé, çà reste bruyant, çà chauffe, et çà consomme.
Si au lieu de laisser allumer son PC en permanence, on pouvait l'allumer seulement pour 2 ou 3 utilisations par jour, sans avoir à anticiper :
Ah oui, je vais consulter mes mails, alors... j'allume mon PC, et je part préparer le repas... bon ! mon PC doit avoir fini de booter. Je me log, je lis mes mails... zut ! çà sent le crâmé.. je cours éteindre sous ma mixture, et je peste contre GNU / linux !
Ajoutons que nous autres qui passons le plus clair de notre temps libre devant un écran ne sommes peut-être pas les plus concernés par le problème, mais la personne qui considère son ordinateur comme un appereil électroménager est sévèrement agacée par ce système conçu pour des serveurs qu'on éteint jamais.
En ce qui concerne l'acpi, ce n'est pas encore magnifiquement au point : sur mon thinkpad avec ubuntu dapper, çà prend presque autant de temps qu'un boot, et j'ai parfois des plantages à la reprise qui m'obligent à redémarrer xorg !
[^]Re: "L'optimisation de l'image du noyau au démarrage"
En ce qui concerne l'acpi, ce n'est pas encore magnifiquement au point : sur mon thinkpad avec ubuntu dapper, çà prend presque autant de temps qu'un boot, et j'ai parfois des plantages à la reprise qui m'obligent à redémarrer xorg !
va regarder les options dans ton /etc/hibernate j'ai du change des trucs dedans pour avoir le suspend comme il faut sans plus de plantage. Evite suspend2 ca marche pas bien, mais bon je suis d'accord avec toi l'acpi c'est pas tip top
[^]Re: "L'optimisation de l'image du noyau au démarrage"
En supposant que l'on considère un niveau de rapidité.. Je connais des boulets pour lesquels un terminal serveur avec des platines qui bootent en 15 secondes c'est trop.. je pense qu'il y a des bugs entre les chaises == la pression du travail
[^]Re: "L'optimisation de l'image du noyau au démarrage"
c'est un confort extrême d'avoir un PC qui boot rapidement
J'ai du mal à comprendre en quoi gagner 3 secondes (allez, disons 10) sur 90 (ou même sur 60) est un confort extrême.
Un PC allumé, çà reste bruyant, çà chauffe, et çà consomme
Admettons que ce n'est pas la solution.
Je me log, je lis mes mails... zut ! çà sent le crâmé.. je cours éteindre sous ma mixture, et je peste contre GNU / linux !
Je peste contre GNU/Linux alors que si mon repas a crâmé, c'est parce que je lisais mes mails ... Evident ! Logique !
C'est pas les 3 secondes (allez, disons 10) de plus au boot qui ont fait crâmé le repas, à moins d'être d'une insondabe mauvaise foi.
Ajoutons que nous autres qui passons le plus clair de notre temps libre devant un écran ne sommes peut-être pas les plus concernés par le problème, mais la personne qui considère son ordinateur comme un appereil électroménager est sévèrement agacée par ce système conçu pour des serveurs qu'on éteint jamais
C'est du n'importe quoi. Ma femme en est très contente justement, que ce soit le linux familial pour lire ses mails, qui lui reste allumé en permanence (et se trouve dans la chambre en plus), que le "media center" du salon qui donne la main à la télécommande en moins d'une minute( faudra que je chronomètre tiens), et dont elle se sert comme un appareil électroménager (enfin, comme d'un magnétoscope super évolué, cause MythTV dessus).
C'est sûr 3 secondes de plus c'est mieux, mais déjà que je la vois pas jubiler quand il est déjà allumé (càd 0 seconde de boot) parce qu'il enregistre une émission, alors je vois pas où est le confort extrême pour quelques secondes de moins.
[^]Re: "L'optimisation de l'image du noyau au démarrage"
euh ... bon ... je vais peut-être aller à l'encontre d'un vent nouveau venu d'ailleurs, mais à part jouer à c'est moi qui ait la plus grosse ca sert à quoi de gagner 3 secondes sur un boot ?
Gagner 3 secondes (voir plus si on en gagne beaucoup plus) les nombreuses fois où l'on boot son micro. Personellement, c'est au moins 2 fois par jour, le matin quand j'arrive au boulot, et le soir chez moi.
C'est aussi gagner 3 secondes chaque fois que tu bootes juste pour regarder 1 truc (une photo, un mail ...). Ce serait tellement bien un micro qui s'allume en moins de 10 secondes !
Le week-end, où j'ai souvent besoin de regarder des trucs, mais de façon ponctuelle, tout au long de la journée, je préfère laisser mon micro allumer, plutôt que perdre du temps à le rebooter sans arrêt. Bonjour l'économie d'énergie !
En plus, c'est quand même bizarre qu'on n'ai quasiment pas gagner de temps sur le boot, malgré les progrès en performance du matériel, surtout que sur d'autres applis, on est passé de temps très long à du quasi instantané.
Vous ne voulez pas rebooter ... mettez votre machine en veille avec l'acpi et vous irez 100 fois plus vite que de bidouiller les inits et autres services ...
L'Acpi ne marche pas sur mon micro. Donc ....
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Tout le monde parle d'optimiser le temps de demarrage via le kernel, a mon humble avis, sur un PC standard (portable ou ordi de bureau), ce qui prend beaucoup de temps, ce n'est pas le demarrage du kernel, mais:
*les scripts d'init (tous ces deamons prennent un temps fous)
*le demarrage de X (bon, pas tant que ca)
*le demarrage de KDE (et la, c'est carrement monstrueusement long).
Donc les efforts ne devraient pas porter sur des optimisations super tordues du kernel, mais sur optimiser les scripts d'init (peut etre en se debarassant de l'heritage que l'on a actuellement, mais j'ai l'impression que cela n'enchante personne) et optimiser les demarrage des gestionnaires de bureau "lourds".
Mathias
[^]Re: "L'optimisation de l'image du noyau au démarrage"
Ton analyse n'est pas fausse, mais je dirais incomplete: pour optimiser réellement le temps de démarrage, il faut optimiser toutes les pièces..
Par exemple, je crois me souvenir qu'une optimisation récente "du kernel" a été de remplacer hotplug par udev et que cela a apporté un gain important.
Pour le démarrage KDE et OOo avaient fournis des patches a glibc pour amméliorer le temps de démarrage mais ils n'ont pas été pris donc ils travaillent sur d'autre contournements.
Pour le démarrage d'X si je me souviens bien un des problèmes est la double initialisation de la carte vidéo: une fois par le kernel, puis par X..