it-swarm-ja.tech

カーネル内でコンパイルされたカーネルモジュールの利点?

(ロード可能なモジュールとしてではなく)カーネルモジュールをカーネルにコンパイルする利点は何ですか?

19
uray

場合によります。メモリが少ない場合は、モジュールが毎回リロードされないため、モジュールを使用すると再開が向上する可能性があります(GiBの2 RAMでは重要ですが、4では重要ではありません) GiB従来のハードドライブ)。これは、バッテリーモジュールのいくつかのバグが原因で(コンパイルまたはモジュールとしてコンパイルされているかどうかに関係なく)、起動に非常に長い時間がかかった場合(数分)に特に当てはまります。 gentooにバグがなくても、静的にコンパイルされたカーネルからモジュールに変更するだけで、(systemd-analysisによって報告された)時間を33秒から18秒に短縮できました。

また、使用するハードウェアがわからない場合、モジュールは明らかに有益です。

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

7

私の知る限り、速度の違いはありません。

割り当ての粒度が1ページであるため、数kBのカーネルメモリが得られると思います。そのため、一般的なアーキテクチャでは、各モジュールはモジュールごとに平均約2 kB(½ページ)を浪費します。組み込みシステムでさえ、それはほとんど重要ではありません。また、モジュールはカーネルと同じ方法で圧縮できるため、ディスク容量も少し増えます。これは、ストレージがほとんどない組み込みシステムに、より関連性があります。

モジュールを完全に省くことができる場合は、カーネルメモリ(モジュールローダーは不要)、ディスク領域(モジュールユーティリティは不要)、およびシステムの複雑さ(ディストリビューションの機能としてモジュールの読み込みを含める必要はありません)を節約できます。 )。これらの点は、ハードウェアが拡張できない一部の組み込み設計では非常に魅力的です。

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

システムで大きなページを利用している場合、おそらくより大きな静的カーネルイメージを作成することは、ページ記述子キャッシュをより効率的に使用することを意味します。一部のシステムでは、カーネルを「ケージ」して1つのメモリローカリティに密にパックします。これにより、マイナーおよび場合によってはメジャーなページフォールトによる遅延がある程度軽減されます。

アーキテクチャ的には、1つの大きなイメージを提供する方が適しているかもしれません。独立したモジュールの数が少ないほど維持が容易であり、柔軟性の低下は重要ではないと主張します。この種の推論の多くは、スタイルと実践の問題に挑戦しています。

4
mfe

時にはそれが必要です。一部のvitalドライバー(SCSIドライバーなど)をモジュールとしてコンパイルすると、システムは起動しません。

モジュールとしてコンパイルするnotのもう1つの優れた候補は、ルートパーティションのファイルシステムタイプです。カーネルが理解できない場合ext3読み取り/lib/modules/どのようにしてモジュールをロードしますか?

このように考えてください。モジュールを使用するには、カーネルがカーネルモジュールを読み取り、ロードするためにシステムについて十分に知っている必要があります。それと試行錯誤してください:-)

2
nc3b

カーネル内の組み込みハードウェアのすべてのドライバーを静的にコンパイルします。例外は、永続的ではないハードウェアです(たとえば、USB接続ハードウェア)。

私のハードウェア構成はすぐには変更されそうにないので、モジュールを気にしません。

2
Stephane