web-dev-qa-db-ja.com

異なるカーネルは、同じマシン上の異なる量の合計メモリを報告します

同じマシン上で同じコードに対してコンパイルされた2つのx86_64カーネルがあります（ Linusのソースツリー の4.15.0）。

構成ファイルは、そのソースに対してmake localmodconfigを実行し、それぞれ異なるディストリビューション（ArchとSlackware）からの異なるより大きな元の構成ファイルを使用して作成されました。ニックネームを付けます

アーチconfig

そして

slkconfig

そのため。

問題：cat /proc/meminfoを実行すると、ArchのMemTotalフィールドでslkよりも約55〜60MB多く報告されます。

MemTotal: 32600808 kB for Arch

vs

MemTotal: 32544992 kB for slk

以前のバージョンのソース（4.15-rcカーネルの束、その前の4.14など、make oldconfigを使用してソースから次のソースにロールオーバー）に対して同じ構成ファイルで実験を試みたため、「一貫して」と言います。 ）。

これはhtopによって報告された数値に反映されており、slkはArchよりも起動時の使用量が約60MB少ないと報告しています。これは、htopの使用メモリ数がMemTotalに基づいている htop devの説明 と一致しています。

私の質問は次のとおりです。どの構成オプションを検討すれば違いが生じるのでしょうか。

もちろん60MB（カーネルが実行されているマシンは32GBです。）は気にしませんが、それは私にとって興味深いパズルであり、学習の機会として利用したいと思います。

Linuxでのメモリレポートは、これらのフォーラムや一般的に外部で頻繁に議論されていますが、この特定のタイプの問題（異なるカーネル/同じマシン=>メモリレポートの異なる結果）を検索しても、関連性があるとは思われません。

編集

@ErikFによってリンクされた投稿の提案に従って、私はの出力を見てみました

journalctl --boot=#

ここで、#は、現在のブートと以前のブート（2つのカーネルに対応）をそれぞれ表す0または-1を表します。これらの線は違いを反映しているように見えるので、それがどこから来ているのかが少し明確になりました。

アーチ（より大きなMemTotalを報告しているもの）：

メモリ：32587752K/33472072K利用可能（10252Kカーネルコード、1157K rwdata、2760K rodata、1364K init、988K bss、884320K予約済み、0K cma-予約済み）

slk（小さいMemTotalを報告するもの）：

メモリ：32533996K/33472072K使用可能（14348Kカーネルコード、1674K rwdata、3976K rodata、1616K init、784K bss、938076K予約済み、0K cma-予約済み）

予想どおり、これは最大55MBの違いです。

/ boot /フォルダー内の2つのvmlinuzファイルのサイズを比較することで確認できるように、slkカーネルの方が大きいことはわかっていますが、違いの主な原因は、2つのそれぞれのカーネルのメモリ量にあるようです。リザーブ。

設定ファイルの内容がthatにどの程度影響するかをよりよく理解したいのですが、これは確かにある程度の光を当てます。

2回目の編集

@TimKennedyによるコメントの質問に答えます。

専用のGPUをお持ちですか、それとも共有ビデオメモリを使用していますか

専用GPUはありません。これは、Intelグラフィックスを搭載したラップトップです。

両方のカーネルが同じグラフィックスドライバーをロードしますか？

はい、i915です。

また、dmesg |の出力を比較します。 grep BIOS-e820 | grep予約済み

さすがに変わらない。すべての場合で12行で、すべての点（メモリアドレスとすべて）が同じです。

（最終？）編集

これと同じくらい簡単かもしれないと思います。MemTotalのレポートが少ないカーネルには、多くの多くのドライバースイートが組み込まれています。私はそれがそのような顕著な違いをもたらすとは思っていませんでした。

私は比較しました：

du -sh /lib/modules/<smaller-kernel>/modules.builtin

4Kを返しますが、

du -sh /lib/modules/<larger-kernel>/modules.builtin

16Kを返します。

したがって、結局、私は間違ったツリーを吠えていると思います。それは単一の構成オプション（または少数）ではなく、より多くの組み込みドライバーの累積効果です。

kernelconfigurationmeminfo
4
grobber

写真は上記の最後の編集と同じだと思います。私が質問したとき、私はメモリを予約するプロセスについて十分に知りませんでした。それはすべて、モジュール化されるのではなく、より多くのドライバが組み込まれているより大きなカーネルに要約されました。

ちなみに、私はこれを（リモートで）実用化したいと思っていました。カーネルをできるだけスリムにしたかったのですが、それでもinitrdなしで起動しました。私はそれを知っていました

  • 小さいカーネル（上記のモニカArch）は非常に軽量で起動が高速ですが、initramfsがないわけではありません。

  • より大きなカーネル（slk）willは、initramfsなしで起動しますが、時間がかかります。

それで、私は今のところ固執すると思う妥協をしました。私は2つの設定ファイルを取り、それらをlargeおよびsmallと呼び、すべての未設定の設定オプションがsmallはlargeに反映されます。

最初、

awk '/^# CO/ {print} small > staging'

smallconfigファイル内の次の形式のすべての行を取得します

# CONFIG_BLAH is not set

そしてそれらをstagingテキストファイルにダンプします。次に、

for i in $(awk '{print $2}' staging) ; do sed -i "s/^$i=./# $i is not set/" large ; done

large（=yまたは=mを介して）に含まれるオプションを設定した構成ファイルからすべての行を取得します/ stagingそしてそれらの設定を解除します。

次に、カーネルソースディレクトリ内の結果ファイルlargeに対してmake oldconfigを実行し、コンパイルしました。それはすべて大丈夫でした：

  • 新しいカーネルは約3秒速く起動します

  • initramfsなし

  • /lib/modules/<kernel>/modules.builtinが16Kから8Kに半分に削減されたという意味ではるかに小さいです。

それらについて書くことはあまりありませんが、私が言ったように、これは私を困惑させました..私は今問題にすべて設定されていると思います。

おそらく、もっと簡単なことは、initramfsなしで起動するためにこのマシンで必要なドライバーを正確に一度だけ把握することでした。 、しかし私はそれを別の日に残しておきます。その上、一方の構成を他方に対して再生することは、それ自体が楽しい演習でした。

0
grobber