> Justement, je me suis fait un noyau TuxOnIce il y a pas longtemps, et le > premier test en mode console n'a pas été concluant : une jolie pile > d'exécution pleine de codes hexa a rempli mon écran, j'ai du utiliser les > raccourcis magiques Alt + SysRq pour sortir sans trop de dégâts. Je vais y > passer des week-ends entiers, je le sens :)
> _________________________________ > Linux mailing list > Linux@lists.parinux.org > http://lists.parinux.org/mailman/listinfo/linux DISCLAIMER : je ne suis en rien responsables des dommages occasionnes a votre phase de boot et votre matÃriel. Notez bien la phrase : sauf si vous savez pertinament ce que vous faites, qui m'avait fait beaucoup rire une epoque! [ DESOLE : POST UN PEU LONG ] Je vais faire de mÃme... Jusque la, j'ai gagne du temps dans les executions en parallelisant et aussi en etalant les executions : il n'est pas interdit de demander a cron ou at de repartir des taches, il ya aussi atd. Alors, concernant le noyau: les meilleurs rÃsultats que j'ai se font avec des noyaux qui datent un peu : 2.6.8 et je ne peut les exÃcuter sur mon dual-core rÃcent cause pb de support. Ne pas oublier que le noyau est un programme qui doit s'executer et qui mettra toujours un certain temps ou un temps certain comme on veut. Tiens d'ailleurs en passant: je n'ai pas ces problÃmes d'accents en console dans les noyaux moins rÃcents : j'ai chargà ©les fonts dans le noyaux et jusqu'au 2.6.18 : impec, mÃme pas besoin de paquets comme les consoles-tools, consoles-fonts, apres cette version, le noyau ne sait pas s'il doit gÃnÃrer de l'unicode, de l'utf-8 ou du latin-15. et Dieu sait les tests que j'ai fait sur ce point. Donc revenons en au fait pour booter vite : 1 bien le dégraisser 2 enlever tout ce qui peut le ralentir 2 utiliser un noyaux moins rÃcent stable ayant tous les supports. AprÃs, tous le reste sont des artifices, qui a mon avis aujourd'hui sont encore expÃrimentaux et risque de de(stable)iliser le noyau. J'ai parcouru google et pour l'instant, je n'ai vu nulle par un vrai bon topo sur le sujet : rendre un noyau rÃcent rapide et lÃger . Ce que je constate : les noyaux rÃcent sont gros et lents. Si je pouvais m'accomoder d'un 2.6.18 sur mon dual-core (ce qui n'est pas le cas) je n'en serai pas plus genà c'est juste question de support aprÃs tout. et le 2.6.18 est un noyau stable. Ou alors, c'est l'inverse : Je crois que mÃme les 2.6.24/28 n'utilisent pas bien les dual-cores. Autre chÃse : Le check des partitions ej : eXfsck -f (je ne parle pas du controle de la journalisation et restore des journeaux) peut trÃs bien pour un pc en utilisation domestique (je ne parle pas de serveur) etre déplaà dans le runlevel 0 : arrêt de la machine. !ATTENTION a bien le placer! Je l'ai fait depuis longtemps et maintenant, je check seulement quand j'arrete ma machine. Je n'ai jamais eu de problÃme sauf en ce moment des messages puisque je reboot souvent pour tests, mais ce n'est pas l'utilisation courante que je fait en principe. C'est drole, mais sur mon bi-proc (cm 775dual-vsti, Pentium 4), et bien mes perfs ne sont pas du tout meilleures que sur mon k7s5a Athlon 1.2 gigas overclockéa 2. pourtant on me donne 3G de frÃquence cpu. Par contre bootchart me dit que trÃs peu de CPU est utilisÃe,et mÃme sur l'athlon ce sont les IOs qui ralentissent le traitement. Finalement, sur les noyaux > 2.6.18 udev est plus intÃressant que de placer les modules en dur dans /etc/modules, bon et puis c'est plus sur. Mais mettre mes modules en dur dans un fichier et me passer de udev ne me gÃne pas non plus: on peu mÃme faire les 2, le chargement des modules ne se fera que si nÃcessaire. Voila : en espÃrant que ca te donnera quelques pistes ainsi qu'aux autres. _________________________________ Linux mailing list Linux@lists.parinux.org http://lists.parinux.org/mailman/listinfo/linux
