Avantage du module noyau compilé dans le noyau?


Réponses:


7

Ça dépend. Si vous avez une petite quantité de mémoire, l'utilisation de modules peut améliorer le CV car ils ne sont pas rechargés à chaque fois (je l'ai trouvé significatif sur 2 Gio de RAM mais pas sur 4 Gio sur les disques durs traditionnels). Cela est particulièrement vrai lorsque, en raison d'un bug dans le module de batterie (qu'il soit compilé ou en tant que module), il a fallu beaucoup de temps pour démarrer (plusieurs minutes). Même sans bug sur gentoo, j'ai réussi à raccourcir le temps (rapporté par systemd-analysis) de 33s à 18s juste en passant du noyau compilé statiquement aux modules - `` étonnamment '' le début du noyau est passé de 9s à 1,5s.

De plus, lorsque vous ne savez pas quel matériel allez-vous utiliser, les modules sont clairement bénéfiques.

PS. Vous pouvez compiler même des pilotes vitaux en tant que modules tant que vous les incluez dans initrd. Par exemple, les distributions incluront le système de fichiers de /, les pilotes de disque dur, etc. dans initrd lors de l'installation.


Cela vous dérange de relire cette réponse, attentivement. Je l'aurais fait, mais je ne sais pas ce que vous vouliez dire sur place, par exemple ... sur les disques durs traditionnels .
tshepang

Je voulais dire magnétiques (je n'ai aucune expérience avec les SSD).
Maciej Piechotka

J'ai essayé de rendre cela plus lisible. Pouvez-vous vérifier si je ne l'ai pas foiré.
tshepang

Merci. Je viens de terminer la session d'examen donc je n'avais pas eu le temps de l'examiner.
Maciej Piechotka

7

Pour autant que je sache, il n'y a pas de différence de vitesse.

Je pense que vous gagnerez quelques Ko de mémoire du noyau car la granularité des allocations est d'une page, donc sur une architecture typique, chaque module gaspille en moyenne environ 2 Ko (½ page) par module potentiel. Même sur les systèmes embarqués, ce n'est guère significatif. Vous gagnez également un peu d'espace disque car les modules peuvent être compressés en même temps que le noyau; qui peut être plus pertinent dans les systèmes embarqués avec peu de stockage.

Si vous pouvez complètement vous passer des modules, vous économisez un peu de mémoire du noyau (pas besoin du chargeur de module), d'espace disque (pas besoin des utilitaires de module) et de la complexité du système (pas besoin d'inclure le chargement de module comme fonctionnalité dans votre distribution ). Ces points sont assez attrayants dans certaines conceptions intégrées où le matériel n'est pas extensible.


Accéder à un symbole dans un module est un tout petit peu plus lent (une indirection est impliquée). Mais la flexibilité supplémentaire (peut charger / décharger selon les besoins, ne pas avoir à construire un noyau personnalisé pour le matériel exact utilisé, ...) en vaut la peine (sauf si vous construisez pour un environnement très contraint qui ne fonctionne pas ne change jamais).
vonbrand

4

Quelques avantages potentiels. La performance est discutable. Vous éviteriez un certain temps d'exécution associé à un chargeur dynamique, mais je doute que ce soit un problème à moins que vous ne dépendiez d'un planificateur en temps réel.

Si vous profitez de grandes pages sur votre système, la création d'une image de noyau statique plus grande signifie peut-être que vous utilisez plus efficacement le cache de descripteur de page. Certains systèmes «encerclent» le noyau de sorte qu'il se compacte étroitement dans une localité de mémoire, ce qui peut réduire un certain délai dû à des erreurs de page mineures, et peut-être majeures.

Sur le plan architectural, il peut vous convenir de fournir One Big Image, en faisant valoir qu'il est plus facile de maintenir moins de modules indépendants et que la perte de flexibilité n'est pas importante. Beaucoup de ce genre de raisonnement s'aventure dans les questions de style et de pratique.


2

Parfois, c'est nécessaire. Si vous compilez un pilote essentiel (par exemple un pilote SCSI) en tant que module, votre système ne démarrera pas.

Un autre excellent candidat pour ne pas compiler en tant que module est le type de système de fichiers de la partition racine. Si le noyau ne comprend ext3pas la lecture, /lib/modules/comment va-t-il en charger des modules?

Pensez-y de cette façon: pour utiliser les modules, le noyau doit en savoir suffisamment sur votre système pour lire et charger les modules du noyau. Utilisez cela et essai et erreur :-)


Je pense à une amélioration des performances? Y en a-t-il du tout?
phunehehe

1
Dans le passé, les gens se sont donné beaucoup de mal pour produire le plus petit noyau possible avec seulement ce qui était nécessaire . Aujourd'hui, cela a largement changé. En fait, chaque fois que vous chargez un module pour la première fois, vous subirez un léger impact sur les performances. Cela ne veut pas dire que vous devez tout compiler dans le noyau :-) Voir ceci: articleinput.com/e/a/title/…
nc3b

pour un pilote ou une fonctionnalité non vital, y a-t-il un avantage? par exemple, si je veux simplement utiliser le terminal et un tas d'utilitaires réseau sans autre besoin ou fonctionnalité. y a-t-il un avantage si je compile juste tous les modules et pilotes nécessaires dans le noyau sans module chargeable?
uray

3
Taureau. Un système démarrera correctement avec un pilote SCSI comme module dans un initrd. C'est pour ça qu'ils sont.
wzzrd

Oui ... à condition que le module soit dans un initrd que le noyau puisse comprendre ...
Dagelf

2

Je compile statiquement chaque pilote pour le matériel intégré dans le noyau. L'exception serait le matériel qui n'est pas permanent (matériel connecté par USB, par exemple).

Comme ma configuration matérielle ne devrait pas changer de sitôt, je ne me soucie pas des modules.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.