Journal : Gestion du matériel gourmande en resources (udev, hal) ?
Posté par Mildred (Jabber id, page perso, ) le 06 juin 2008
0
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 ?
> Lire le journal (37 commentaires, moyenne: 2,9).
Vous avez demandé le commentaire #938301.
Run by 
Cette page a été générée par Templeet en 0.0617s (dont 0.0061 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
C'était mieux avant.
Il y a toujours la possibilité de compiler judicieusement son kernel puis configurer son système pour se passer de HAL ou udev.
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.
avec tous les périphériques usb que l'on a maintenant (disques durs externes, clé usb, appareils photos), Hal c'est bien pratique tout de même. Et en plus on a moins de messages sur les forums linux genre "je n'arrive pas à écrire sur ma clé usb..."
You can't grep dead trees...
[^]Re: C'était mieux avant.
j'ajouterais que je n'ai pas vraiment remarqué de problème avec udev, mais je n'ai pas trop cherché à comprendre non plus. En tout cas, j'avais un gros goulot d'étranglement avec FAM, qui de temps en temps bloquait les processus d'ouverture de fichier, et je me porte pas plus mal depuis que je l'ai effacé. (mais là on s'éloigne de la gestion du matériel).
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)
You can't grep dead trees...
[^]Re: C'était mieux avant.
Et en plus on a moins de messages sur les forums linux genre "je n'arrive pas à écrire sur ma clé usb..."
Sinon, on peut aussi enlever les pilotes de la carte réseau.
[^]Re: C'était mieux avant.
Et en plus on a moins de messages sur les forums linux genre "je n'arrive pas à écrire sur ma clé usb..."
et moins de journaux linuxfr avec cette même question
[^]Re: C'était mieux avant.
Avant udev/dbus/Hal la reconnaissance automatique du matériel relevait plus du coup de chance et du savoir faire des distributeurs.
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.
Slackware depuis 1996
[^]Re: C'était mieux avant.
les périphériques sont systématiquement compilés sous forme de modules […] sur des machines anciennes c'est un frein considérable.
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.
En ce qui me concerne sur ma machine perso , j'ai une économie de RAM d'environ 50 MB et un temps de boot un peu plus court au pif une dizaine de secondes
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...
Slackware depuis 1996