L'idée est :
posons nous en situation ou, un démarrage de noyau se fait avec le même matériel dans le meme état physique, ne serait-il pas possible de sauvegarder un état du noyau juste avant l'appel à init, pour raccourcir les temps de démarrage ?
Bon, est-ce une idée valable ?
Question/Obstacle 1: en fait le temps, c'est l'initialisation du matériel physique et non pas du noyau ?
Question 2 : est-ce que il n'y a pas des endroits ou ça reste valable comme idée ? genre, l'init de mapping bios, le bogomips, la console, la mémoire, .. ?
qu'est-ce que t'en pense journal ?
Journal idée : Un kernel qui boute plus vite
30
juin
2004
# idée : Un kernel qui boute plus vite
Posté par chl (site web personnel) . Évalué à 2.
Par contre, je n'ai plus l'URL ...
[^] # Re: idée : Un kernel qui boute plus vite
Posté par Frédéric Rodrigo . Évalué à 4.
[^] # Re: idée : Un kernel qui boute plus vite
Posté par 007 . Évalué à 4.
Le boot en parallèle permet de gagner du temps mais il a le défaut d'avoir un moins bon contrôle sur l'ordre de lancement des services et être plus confus dans l'affichage détaillé.
FC2 lance les script readahead_early readahead dès le début du boot. Ces scripts lancent en tache de fond le programme /usr/sbin/readahead. Sa fonction est simple : lire le début d'une liste de fichier. Ses fichiers sont normalement lu lors d'une séquence de boot et un login graphique.
La liste des fichiers à lire est établie avec un noyau spécial (utilisé uniquement en phase de développement) qui loggue tous les fichiers accédés.
Donc on a une boot séquenciel "classique" avec en parallèle des accès disques pour mettre en cache les prochains accès. Ça accélère significativement. Je gagne presque 10 secondes.
# Contre la montre....
Posté par TheBreton . Évalué à 9.
Voici quelque éléments de réponse.
PB 1) Ton PC boot sur un bios qui fait deja sa vie et prend sont temps
Soluc 1) le projet linuxbios consiste a mettre le bios minimal de linux
PB 2) Lors de la phase de boot le kernel (et le systeme) est mono-thread par ecriture et par necessité (init du proc, du disq,puis de la video,du clavier...)
Soluc 2) travail en cours dans le kernel et dans les drivers
PB 3) Certains periph on besoin d'etre sortie de l'etat reset puis mette leur temps a demarrer (ex:disque scsi,ide....)
Soluc 3) travail en cours sur le materiel destiné au application embarqué qui finiras bien par remonté au monde sur table
PB 4) Les tonnes de truc inutiles qu'un Linux installé de distrib lance et qui servent a rien (en boot time en tout cas) et pourrais etre lancé manuellement quand le besoin est la.
Soluc 4) le vieux devfs et le nouveau udev devrait servir de base a des evolutions possible pour les autres bus (pci, hyper transport). Les install LFS (linux from scratch) sont des monstres de rapidité en boot time dont bon courage a toi pour cette merveilleuse aventure :-)
# autre idée
Posté par lukeg . Évalué à 3.
Toutes les grandes distributions nous refilent un noyau tout compilé, tout beau, tout chaud.
La plupart maintenant font de la détection de matériel à l'install, et nous chargent les modules correspondant
Ne pourrait-ont pas "combiner" les 2, c a dire détecter le matériel, et recompiler un noyau avec les options spécifiques à notre matériel deja activées? Avec en + quelques questions (kernel préemptif...), et roule jeunesse? On aurait ainsi un noyau plus minimal, qui pourrait booter + vite (si on a pas tout mis en modules)
Car meme en connaissant sa machine, il est parfois difficile de savoir si on a besoin de ca ou ca...
Enfin bon, c juste une idée comme ca, c peut etre déjà implémenté ou y'a des problèmes que je ne vois pas du premier coup d'oeil
[^] # Re: autre idée
Posté par Pascal . Évalué à 5.
Cependant, l'installation de Linux doit être la plus simple possible et poser le moins de questions possibles pour un débutant.
Imagine quelqu'un qui installe Linux pour la première fois, et l'installateur lui pose la question:
<< Bonjour petit gars, je vais compiler ton noyau; Est-ce que tu le veux préemptible ou pas? >>
Et puis, cela rajouterait enormement de complexité dans le programme d'installation, et augmenterait le risque que l'installation foire et que le système ne marche pas au premier essai.
De plus, Linus a bien fait son travail puisque le noyau est modulaire, et dans les distributions, le maximum de trucs sont en général compilés en modules. Ce qui fait que les noyaux des distributions ne sont pas vraiment plus lourd, ni plus lent qu'un noyau parfaitement adpaté à la machine.
[^] # Re: autre idée
Posté par Bapt (site web personnel) . Évalué à 2.
Je ne suis pas d'accord, moi ce qui me plait dans linux, c'est de pouvoir avoir des distribs qui font ce que tu dit pour les débutants, et ceux qui ne veulent pas ce faire chier, mais moi je suis preneur d'un distrib qui recompile mon noyau, c'est d'ailleurs pour ca que j'utlise gentoo ou slack, on me fait pas chier, on me laisse faire.
Bref : vive la diversité, des distribs simple d'autres plus complexes, et globalement toujours la possibilité de faire ce qu'on veut puisque derrière ca reste du linux ;)
[^] # Re: autre idée
Posté par 007 . Évalué à 1.
Prends n'importe qu'elle distribution rpm-based et on te fera pas chier, on te laisse faire et tu peux recompiler ton noyau.
Il y a des tonnes et des tonnes de personnes qui savent parfaitement ce que leur "grosse" distribution fait et qui en font ce qu'ils veulent avec. La distinction avec Gentoo, sourcemage, etc n'est vraiment pas là.
> globalement toujours la possibilité de faire ce qu'on veut
là je suis d'accord :-)
[^] # Re: autre idée
Posté par Narishma Jahar . Évalué à 2.
Je ne sais pas par contre ce qu'il en est des performances, ne l'ayant jamais testé.
# Hibernation
Posté par Ramso . Évalué à 2.
[^] # Re: Hibernation
Posté par Temsa (site web personnel) . Évalué à 1.
[^] # Re: Hibernation
Posté par ckyl . Évalué à 3.
Y'a une machine que je n'ai jamais reussi a reveiller.
Autrement si on fait un calcul rapide avec 1Go de RAM.
1/ ca bouche 1Go de swap
2/ 1000 / 50 = 20 sec pour faire le resume.
Le gain est pas enorme par rapport au gain au temps de boot sur ma sourcemage en simpleinit. De plus le resume du reseau peu presenter quelque problemes pour les applis.
Bref c'est utile mais pas super au point je trouve. Sur mon ibook sous OS X ca marche vraiment du tonere par contre il me senseble que c'est du suspend en RAM et non sur disque (donc tres rapide a la reprise).
Pour l'optimisation OS X a un super truc (qui a l'air de se raprocher de ce dont 007 parlait sur FC) c'est de garder en memoire les access disque lors du boot. Et de precharger d'un coup ce dont on est presque sur d'etre utile. Plus tu boot plus ton boot est performant :-)
# Mise en veille
Posté par Jllc . Évalué à 1.
On peut carrément mettre la machine en veille (si on ne fait pas de multiboot). Mon dernier micro ne me le permet pas (ACPI encore mal géré), mais sur mon ancien, l'APM marchait parfaitement, et les réveils après mise en veille était très rapide.
# But where is the bottleneck ?
Posté par snt . Évalué à 0.
( et oui j'utilise kde ... )
# precaching...
Posté par lezardbreton . Évalué à 2.
# Mmmm
Posté par boris . Évalué à 2.
Même dans le cas de l'hibernation, le noyau repasse par cette phase d'initialisation au réveil.
# Et un vrai système de boot plus rapide?
Posté par Temsa (site web personnel) . Évalué à 1.
Ca demanderai de refaire les scripts des services(sans forcément en changer l'utilisation, quoiqu'on pourrait y remplacer par des sortes de plugin...), mais mis à part ça je vois pas de désavantage...
[^] # Re: Et un vrai système de boot plus rapide?
Posté par 007 . Évalué à 0.
Donc pas de gain significatif à attendre avec python au-lieu de bash.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.