同じコンピュータ（4.15.0）で同じコード用にコンパイルされた2つのx86_64カーネルがあります。Linusのソースツリー）。
構成ファイルは、make localmodconfigそれぞれArchやSlackwareなどのさまざまなディストリビューションの異なるより大きなソース構成ファイルを使用してこのソースに対して実行することによって生成されます。私は彼らにニックネームを与える
アーチ 構成
そして
シルク 構成
だから。
問題：cat /proc/meminfo一貫したレポートを実行すると、MemTotalフィールドに約55〜60 MBがあります。アーチ比較するシルク:
MemTotal: 32600808 kB~のためアーチ
そして
MemTotal: 32544992 kB~のためシルク
私が「一貫して」と言ったのは、同じ構成ファイルを使用して以前のバージョンのソース（1つのソースから次のソースにローリングする複数の4.15-rcカーネル、以前の4.14など）で実験を試みたためですmake oldconfig。
これはhtopによって報告されたデータに反映されます。シルク起動時の使用率の報告アーチ。これは以下に関連しています。htop開発者の説明htopの使用されたメモリデータはMemTotal。
私の質問は：どの設定オプションを調べるべきかについての提案が影響を与える可能性があるということです。
もちろん、60MB（カーネルを実行するマシンには32GBがあります）は問題ではありませんが、これは私にとって興味深いパズルであり、学習機会として使用したいと思います。
Linuxのメモリレポートはこれらのフォーラムと外部で広く議論されていますが、これらの特定の種類の問題（他のカーネル/同じマシン=>メモリレポートの他の結果）を検索しても関連性があると考えられるものはありませんでした。
編集する
@ErikFがリンクした投稿のアドバイスに従って、次の出力を見てみました。
journalctl --boot=#
これは#、それぞれ現在と最後の開始（2つのコアに対応）を表す0または-1を表します。線は違いを反映しているようで、今、その違いがどこから来たのかがより明確になりました。
アーチ（より大きなMemTotalを報告すること）：
メモリ：32587752K / 33472072K利用可能（10252Kカーネルコード、1157K rwdata、2760K rodata、1364K init、988K bss、884320K予約済み、0K cma予約済み）
シルク（より小さいMemTotalを報告すること）：
メモリ：32533996K / 33472072K利用可能
予想通り、違いは約55MBです！
わかりましたシルク/boot/フォルダ内の2つのvmlinuzファイルのサイズを比較すると、カーネルは大きくなりますが、違いの主な部分は、2つの各カーネルが予約したメモリ量から生じるようです。
設定ファイルへの影響をよりよく理解したいと思います。それそれはある程度真実ですが、ある程度明らかになりました。
2番目の編集
コメントで@Tim Kennedyの質問に回答します。
専用のGPUがありますか、共有ビデオメモリを使用していますか？
専用GPUはありません。 Intelグラフィックスを内蔵したノートパソコンです。
どちらのカーネルも同じグラフィックドライバをロードしますか？
うん、i915。
また、dmesg | grep BIOS-e820 | grep BIOS-e820 | grep BIOS-e820 grep Reserved の出力を比較します。
予想通り、何も変わらなかった。すべての場合は12行で、すべての側面（メモリアドレスなど）が同じです。
(最終?) 編集
私はそれがとても簡単だと思います：カーネルはより少ないMemTotalを報告します。たくさんより多くの組み込みドライバーファミリがこのような顕著な違いを生むとは知らなかった。
私は比較した:
du -sh /lib/modules/<smaller-kernel>/modules.builtin
4Kに戻る間
du -sh /lib/modules/<larger-kernel>/modules.builtin
16Kを返します。
だから結局私は間違った木を吠えると信じています。単一の設定オプション（または少数）ではなく、より多くの組み込みドライバの累積効果になります。
ベストアンサー1
私は写真が上記で最後に編集されたのと同じだと思います。この質問をしたとき、私はそれを実装するためにメモリを維持するプロセスについて十分に知りませんでした。すべては、より多くのドライバが組み込まれたより大きなカーネルに帰結します。モジュール性より。
ところで、私はこれを（リモート）実用的な用途に活用したいと思います。できるだけ簡潔なカーネルを持ちたいのですが、まだinitrdなしで起動したいと思います。わかりました
小さいコア（別名アーチ上）は非常に軽くて起動が速いですが、initramfsがなければそうではありません。
大きなコア（シルク)〜するinitramfsなしで起動できますが、時間がかかります。
だから妥協をして、しばらくはその妥協案にこだわると思います。 2つの設定ファイルをインポートして呼び出しました。大きいそして小さい、設定されていないすべての設定オプション小さい反映大きい。
まず、
awk '/^# CO/ {print} small > staging'
すべての行を取得小さい構成ファイルの形式は次のとおりです。
# CONFIG_BLAH is not set
そしてそれらを捨てなさい分割火テキストファイル。次に、
for i in $(awk '{print $2}' staging) ; do sed -i "s/^$i=./# $i is not set/" large ; done
構成ファイルからすべての行をインポートします。大きい=yまたはで=m次のオプションを設定します。分割火設定を解除します。
make oldconfig次に、生成されたファイルを実行します。大きいカーネルソースディレクトリに入れてコンパイルします。すべて最もよい:
新しいカーネルは約3秒早く起動します。
initramfsなし
/lib/modules/<kernel>/modules.builtin16Kが8Kに半分に減るという点ではるかに小さい。
このうち何も家に書く内容ではありませんが、私が言ったように混乱していました。私の考えでは、今はその内容を理解しているようです。
おそらくより直接的なアプローチは、一度に調べることです。正確にinitramfsなしで起動するには、このシステムにどのドライバが必要ですか？しかし、これについては別の日に残しておきます。さらに、ある構成を他の構成と比較することは、それ自体が興味深い作業である。