Bonsoir,
Suite au récent journal parlant de la manière d'installer GNU/Linux sur un vieux PC, et à des pensées personnelles, je me demande jusqu'à quel point la gestion du matériel peux prendre des ressources (je pense au temps CPU au démarrage).
En effet, j'ai bien l'impression que udev et HAL [http://en.wikipedia.org/wiki/HAL_(software)], à eux deux, consomment pas mal. je n'ai pas de chiffres, mais il me semble que c'est ce qui met le plus de temps à démarrer. De plus on voit des gens se plaindre de la lenteur d'udev (que j'ai rencontrée moi même, à une moindre échelle), et une dépêche récente parle des problèmes de HAL [http://linuxfr.org/2008/05/08/24045.html]
Alors voilà, la question est ouverte.
Je suppose que si cela prend du temps, c'est qu'il faut tester toutes les combinaisons possibles de matériel. Et comme finalement, GNU/Linux support nativement plein de matériel, ça fait plein de tests à faire.
Serait il possible de mettre en cache le résultat de cette investigation ? Comme ça, ça prend du temps juste la première fois. Ensuite tout est cherché en cache. Bien sûr il faudrait faire quelques petits tests pour voir si il n'y a pas eu de changement, mais on pourrait penser que c'est plus rapide ...
En regardant comment le EEEpc ou d'autres pc similaires peuvent faire booter Linux rapidement sur une config matérielle maîtrisée, on peut raisonnablement en déduire que le problème de performances vient bien de là.
Qu'en pensez vous ?
Journal Gestion du matériel gourmande en resources (udev, hal) ?
6
juin
2008
# Temps variable
Posté par claudex . Évalué à 1.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Temps variable
Posté par gst . Évalué à 2.
[^] # Re: Temps variable
Posté par Obsidian . Évalué à 4.
[^] # Re: Temps variable
Posté par liberforce (site web personnel) . Évalué à 3.
[^] # Re: Temps variable
Posté par Obsidian . Évalué à 3.
En général, un petit Ctrl-C permet de vite passer à la suite (quitte à rappeler soit même pump ou dhclient une fois loggué s'il n'y a pas déjà un daemon pour s'en charger).
[^] # Re: Temps variable
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Temps variable
Posté par Obsidian . Évalué à 3.
[^] # Re: Temps variable
Posté par gnumdk (site web personnel) . Évalué à -1.
Parce que la splash screen d'Ubuntu ne permet pas de savoir qu'un fsck est en route donc effectivement, parfois, on peut se demander se que fait la machine...
Chez moi, sur ma debian, c'est fsck à l'arret du PC. Ca évite d'attendre trois plombe au démarrage.
[^] # Re: Temps variable
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Temps variable
Posté par ʭ ☯ . Évalué à 2.
Le problème introduit par ces facilités est qu'effectivement, un périphérique peut retarder le démarrage de toute la machine...
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Temps variable
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Temps variable
Posté par Mildred (site web personnel) . Évalué à 2.
Genre sleep 20s si je ne trouve pas un périphérique dont je dépend (enfin ce n'est sûrement pas aussi gros)
[^] # Re: Temps variable
Posté par Nicolas S. . Évalué à 1.
Ce n'est plus le cas. Avec la mise à jour en Hardy, j'ai eu la surprise de découvrir qu'un message apparaissait sur le splash screen avec le détail des opérations en cours.
[^] # Re: Temps variable
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: Temps variable
Posté par dawar (site web personnel) . Évalué à 3.
De toute façon, le fsck, c'est tous les 30 montages, donc tous les mois environ pour moi qui éteins ma machine tous les soirs.
Enfin, sur Hardy, je trouve le temps de démarrage tout à fait correct. Jusqu'a GDM, c'est plus rapide que de GDM au bureau Gnome avec Compiz qui fait cuicui.
[^] # Re: Temps variable
Posté par Sufflope (site web personnel) . Évalué à 2.
[^] # Re: Temps variable
Posté par duf . Évalué à 2.
De toute façon ça se remarque fortement, car entre 30s pour un boot normal, sur le portable de ma copine le boot passe facilement à 2min quand il fait le fsck.
# C'était mieux avant.
Posté par Grumbl . Évalué à 2.
C'était d'ailleurs comme ça qu'on faisait avant, et je suppose que c'est ce que font les vendeurs qui livrent leur hardware préconfiguré avec Linux.
[^] # Re: C'était mieux avant.
Posté par B16F4RV4RD1N . Évalué à 5.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: C'était mieux avant.
Posté par B16F4RV4RD1N . Évalué à 3.
En tout cas un cache pour le matériel, cela pourrait être bien vu que ce n'est pas souvent que je modifie mon ordinateur. (je pensais qu'il y en avait déjà un)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: C'était mieux avant.
Posté par Larry Cow . Évalué à 8.
Sinon, on peut aussi enlever les pilotes de la carte réseau.
[^] # Re: C'était mieux avant.
Posté par teddyber . Évalué à 2.
et moins de journaux linuxfr avec cette même question
[^] # Re: C'était mieux avant.
Posté par Unixfix le Gaulois . Évalué à 4.
Aujourd'hui grâce à udev/dbus/Hal à peu près toutes les distributions se valent en terme de reconnaissance matérielle. Cela est à payer au prix fort: Le démarrage est devenu lent car les distributions sont conçues de telle sorte qu'à peu près tout ce qui est supportable est supporté y compris les pilotes propriétaires.
Pour en arriver la, les périphériques sont systématiquement compilés sous forme de modules et chargé à la demande en fonction des résultats de l'évaluation faite par udev. Sur des machines ayant mémoire à profusion et des CPUs dernier cri cela ne se sent pas trop. Par contre sur des machines anciennes c'est un frein considérable.
Pour remédier à cet état de fait, recompiler le kernel est une option qui apporte énormément. Pour ma part je compile mon kernel de telle sorte que le matériel non amovible (CPU type, ACPI, Ethernet, Carte graphiques, etc…) est directement intégré au noyau et non sous forme de modules. Un gain sensible de performance est indéniable.
D'autre part et cela pour satisfaire tout un chacun tous les services existants sont démarrer par défauts dans la plupart des distros grand public. Si les utilisateurs de tels ou tels services seront satisfaits, ceux qui ne les utilisent pas traine un ballast inutile ralentissant le démarrage et consomme de la mémoire pour rien. Une revue des scripts de démarrage apporte aussi un gain de performance non négligeable surtout sur les machines un peut juste en mémoire et au processeur plus très frais.
[^] # Re: C'était mieux avant.
Posté par Sylvain Sauvage . Évalué à 2.
Des chiffres ?
Pour remédier à cet état de fait, recompiler le kernel est une option qui apporte énormément.
Idem.
Un gain sensible de performance est indéniable.
Sans plus d’arguments, je dénie. Na.
[^] # Re: C'était mieux avant.
Posté par Unixfix le Gaulois . Évalué à 2.
Certe ce n'est pas gigantesque mais ce n'est pas non plus négligeable!
Au Boulot on travaille sur du temps réel et là il n'a y a pas de petite économie. Tout ce qui est inutile est jeté par dessus bord....
Là on obtient un gain en performance de l'ordre de 50 % sur une config standard...
# udev sux
Posté par asteroid . Évalué à 10.
Est ce qu'on va installer Vista, quitte à désactiver les effets de bureau, sur un duron 700 ? Faudrait être un peu con il me semble. Alors pourquoi un ubuntu ou une mandriva 2008 devrait marcher ? Les dévellopeurs ne sont pas des magiciens, ils utilisent les technologies _actuelles_ pour faire marcher au mieux leurs outils.
Est ce que windows 98 n'a pas besoin qu'on installe explicitement un à un les pilotes de la carte son, du bus usb, des chipsets, etc ... ? Fait pareil avec ton linux au lieu de le laisser utiliser udev pour trouver tout seul quel module charger, et en effet, il démarrera bien plus vite, et t'auras les même emmerdes qu'avec win 98 en ce qui concerne les clés usb et autres APN. Tu seras aussi emmerdé à l'ajout de chaque nouveau matériel, pour trouver tout seul le bon pilote et faire en sorte qu'il se charge au démarrage.
Amha il faut comparer du comparable, et arrêter de cracher dans la soupe qu'on bouffe tous les jours parce qu'un kéké ne sait pas comment marche son OS. Sans udev, c'est garantit que linux ne serait pas tant utilisé (parfois on se demande si ça serait pas mieux), il faut juste regarder en arrière les première distributions "grand public", red hat et autre Mandrake. Ça marchait parfois, mais au niveau périphériques c'était toujours la merde : problème de reconnaissance, de droit, duplication des /dev, .... Et oui, à cette époque udev n'existait pas. Tous ces soucis n'existent plus aujourd'hui.
Pour finir, un petit exemple : j'ai un Duron 700 qui tourne h24 avec mon serveur de fichier, d'impression, mon blog, ma forge, et un tas de saloperie. Il a une slackware 12.0. Bien sûr par de clavier pas d'écran, ... ça sert à rien dans ce cas. La prochaine machine sera un bien plus vieux que ça, au mieux un Pentium 1 ou pire un vieux IBM trouvé aux poubelles avec 8Mo de ram, pour gérer un peu de domotique. Je pourrais installer vista dessus ? parce que j'ai vu qu'il existait des bons outils domo sous vista ... bon pas grave, si je peux pas, je me contenterais d'une Slackware, encore sans X ... putain linux ça pu, on peut rien faire avec !
[^] # Re: udev sux
Posté par Mildred (site web personnel) . Évalué à 4.
A mon avis, ce serait possible de mettre en cache les pilotes que udev doive charger (au lieu de réévaluer toutes ses règles au démarrage). Ça prendrait sans doute moins de temps. Bien sûr il faut un système qui détecte quand le cache est devenu obsolète aussi.
Pour ce qui est de l'installation manuelle des pilotes, pourquoi pas ? Sauf qu'a l'haure actuele ce n'est pas comme W98 ou on avait un suivant/suivant/terminer, mais c'est plus recompilation de kernel et/ou modification des scripts de démarrage. Autrement moins simple.
[^] # Re: udev sux
Posté par Vador Dark (site web personnel) . Évalué à 1.
->Chaque fois qu'un périphérique est branché pour la première fois, une base de donnée est mise à jour pour "retenir" que le matériel est suscéptible d'être branché.
->Au démarrage, dans un premier temps, seul les périphériques de la base de donnée sont testés, et les pilotes chargés si nécessaire.
->Une fois le bureau complètement chargé, celui-ci envoi un message sur dbus, qui provoque le scan complet du matériel, et si un nouveau matériel est détecté une trayicon indique que le nouveau périphérique est prêt à l'emploi(ou que l'OS télécharge les paquetages réquis, les install, et enfin que le matos est ready for use).
[^] # Re: udev sux
Posté par Ph Husson (site web personnel) . Évalué à 1.
[^] # Re: udev sux
Posté par Vador Dark (site web personnel) . Évalué à 1.
[^] # Re: udev sux
Posté par Olivier Ponchaut . Évalué à 3.
De mon expérience, sur un PC identique, Linux démarre généralement plus vite que Windows. Tout dépend de ce que l'on entend par "booter" bien sur. Pour moi, le chrono ne s'arrête pas quand le bureau est affiché (comme c'est le cas très rapidement avec Windows), mais bien quand il est possible d'effectuer une action avec son PC.
Pour faire un test comparable, je teste l'ouverture du PC depuis le moment ou on appuie sur le bouton start jusqu'à l'ouverture d'un explorateur de fichier. Et bien dans ces conditions, ma distribution linux (Arch avec KDE) démarre plus vite que Windows XP ... même si le bureau est affiché plus vite sous windows ... ce n'est plus vrai lorsqu'il y a un fsck du HD ... mais je préfère quand même que mon système de fichier soit vérifié régulièrement.
Et vous quel est votre expérience ?
[^] # Re: udev sux
Posté par Mildred (site web personnel) . Évalué à 3.
Udev est un bon logiciel je pense, mais je pense aussi qu'il peut être amélioré.
[^] # Re: udev sux
Posté par herodiade . Évalué à 6.
udev & hal sont donc la partie « visible » (ou userspace) de ce temps d'initialisation des périphériques, mais n'en sont pas responsable pour autant. Le symptôme, pas la maladie, etc.
[^] # Re: udev sux
Posté par Thomas Douillard . Évalué à 5.
Genre pour le lecteur CD, on doit pouvoir faire pleins de trucs le temps qu'il lance son moteur et lise un peu le CD ...
# Profilage
Posté par Sylvain Sauvage . Évalué à 4.
Donc vérifiez vos dires.
Le bon module est la plupart du temps trouvé par les identifiants Vendor et Product, en regardant simplement dans un table (les fichiers *map dans le répertoire contenant les modules). Donc ce n’est pas le lien matériel→module qui prend(rait) du temps. À la rigueur, la lecture du module sur le disque… ah ben non, beaucoup sont dans le initramfs, donc déjà en mémoire…
[^] # Re: Profilage
Posté par Batchyx . Évalué à 2.
[^] # Re: Profilage
Posté par Mildred (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.