カーネル内でカーネルモジュールをコンパイルすると、どのような利点がありますか？

時々違うよねメモリ量が少ない場合、モジュールを使用すると毎回リロードされないため、履歴書が向上する可能性があります（2GiB RAMでは重要ですが、既存のハードドライブの4GiBでは重要ではありません）。これは、バッテリモジュール（コンパイルされた、またはモジュールとして）のいくつかのバグが原因で起動時間が長い場合（数分）、特にそうです。 Gentooにバグがなかったにもかかわらず、カーネルを静的にコンパイルすることからモジュールに変更するだけで（報告されているように）時間をsystemd-analysis33秒から18秒に短縮でき、「驚くべきことに」カーネルの起動時間が9秒から1.5秒に変更されました。 。

また、モジュールは、どのハードウェアを使用したいのかわからない場合には確かに便利です。

PS。 initrdに重要なドライバが含まれている限り、それをモジュールにコンパイルできます。たとえば、ディストリビューションには、インストール時にinitrdに/ファイルシステム、ハードドライブなどが含まれます。

私が知っている限り、速度にはあまり違いはありません。

割り当て単位が1ページなので、数kBのカーネルメモリを得ることができると思うので、一般的なアーキテクチャでは、平均的にモジュールあたり約2kB（1/2ページ）を無駄にすることになります。組み込みシステムでもこれはあまり意味がありません。また、モジュールをカーネルと同時に圧縮できるため、少しのディスク容量を確保できます。これは、ストレージスペースの少ない組み込みシステムに適しています。

すべてのモジュールを捨てることができれば、わずかなカーネルメモリ（モジュールローダは不要）、ディスクスペース（モジュールユーティリティは不要）、およびシステムの複雑さ（デプロイメント機能でモジュールをロードする必要はありません）を節約できます。 。これは、ハードウェアを拡張できない一部の組み込み設計では非常に魅力的です。

いくつかの潜在的な利点があります。パフォーマンスは議論の余地がある問題です。ダイナミックローダに関連するランタイムオーバーヘッドの一部を回避できますが、リアルタイムスケジューラに依存しない限り、大きな問題ではないと考えられます。

システムが巨大なページを利用する場合、より大きな静的カーネルイメージを生成することにより、ページ記述子キャッシュをより効率的に使用することができる。一部のシステムはカーネルを「ケージ」して単一のメモリ位置にしっかりと圧縮し、マイナーで深刻なページエラーによる待ち時間を軽減できます。

構造的に言えば、1つの大きな画像を提供するのが適切かもしれません。独立モジュールの数が少ないほど、メンテナンスが容易で柔軟性の損失が大きくないと考えるからです。これらの推論の多くは、スタイルと実践の問題に関連しています。

カーネルに組み込まれているハードウェアのすべてのドライバを静的にコンパイルします。非永続的なハードウェア（USB接続ハードウェアなど）は例外です。

私のハードウェア構成はすぐに変更される可能性が低いため、モジュールには興味がありません。