☰

システムメモリ...特に「tmpfs」、「shm」、「hugepages...」の違い

tag-icon • tag-icon linux filesystems memory tmpfs shared-memory
システムメモリ...特に「tmpfs」、「shm」、「hugepages...」の違い

最近、Linuxカーネルメモリベースのさまざまなファイルシステムについて疑問に思いました。

Note:私が考える限り、次の質問は、タイトルで尋ねられた質問をよりよく理解することと比較して、やや選択肢と見なされるべきです。以下に質問する理由は、答えを与えることが違いを理解するのに役立つと思うからです。しかし、私が理解した範囲が本当に制限されているので、他の人がもっとよく知っているかもしれません。タイトルに記載されている3つのファイルシステム間の違いの理解を高めるのに役立つすべての答えを受け入れる準備ができています。

最終的に利用可能なファイルシステムをマウントしたいと思います。hugepages,少し軽い研究（そしてより軽いはんだ付け）のために私は信じていました。rewritable hugepage mountオプションではありません。私は間違っていますか？ここでのメカニズムは何ですか？

また、薬hugepages:

     uname -a
3.13.3-1-MANJARO \
#1 SMP PREEMPT \
x86_64 GNU/Linux

    tail -n8 /proc/meminfo
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     8223772 kB
DirectMap2M:    16924672 kB
DirectMap1G:     2097152 kB

（ここではフルテキストバージョンを見ることができます。/proc/メモリ情報そして/proc/cpuについて)

上記のような状況では何が起こっているのでしょうか？私は割り当てましたか？hugepages?間に違いがありますかDirectMapメモリページとhugepages?

修正する@Gillesからちょっとした促しを受けた後、上に4行を追加しましたが、違いがあるようです。聞いたことはないけどDirectMapそれを引く前にtail昨日…おそらくDMIまたは他のもの？

もう少し...

何の成功もなくhugepages努力し、すべてのイメージファイルのハードドライブのバックアップを想定します。ループの設置による危険は何ですか？tmpfs?私のファイルシステムはswapped最悪のシナリオは何ですか？わかりました。tmpfsマウントされたファイルシステムキャッシュ - メモリ不足のためにマウントされたループファイルがストレスを受けますか？これを防ぐために取ることができる緩和策はありますか？

最後に - 正確には何ですか？shm,それでも？それはどのように異なるか含まれますか？hugepagesまたはtmpfs?

ベストアンサー1

tmpfsとshmの間に違いはありません。 tmpfs は shm の新しい名前です。 shm は共有メモリを表します。

望むより：Linux一時ファイルシステム。

今日のtmpfsを使用する主な理由は、私のGentooコンピュータの/ etc / fstabにあるこのコメントです。ところで、次の行がないと、Chromiumはビルドされません。

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for 
# POSIX shared memory (shm_open, shm_unlink). 
shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0

~からLinuxカーネルファイルシステム文書

引用:

tmpfsの用途は次のとおりです。

  1. カーネル内には見えないマウントが常に存在します
    。これは、共有匿名マッピングおよびSYSV共有
    メモリに使用されます。

    このマウントはCONFIG_TMPFSに依存しません。 CONFIG_TMPFSが設定されていない場合、tmpfsのユーザーに表示される部分は構築されません。しかし、内部
    メカニズムは常に存在します。


  2. glibc 2.2以降では、tmpfsはPOSIX共有メモリ（shm_open、shm_unlink）用の/ dev / shmにマウントされると予想しています。 /etc/fstab に次の行を追加すると
    問題が解決します。

tmpfs /dev/shm tmpfs デフォルト 0 0

必要に応じて、tmpfsがマウントされるディレクトリを作成することを忘れないでください。

このマウントはいいえSYSV 共有メモリーに必要です。内部
マウントはこの目的に使用されます。 （2.3カーネルバージョンでは、SYSV共有メモリを
使用するためにはtmpfsの全身（shm fs）をマウントする必要があります）


  1. 私を含む一部の人は、これを/ tmpと/ var / tmpにインストールし、大きなスワップパーティションを持つことが便利だと思います。これで
    tmpfsファイルの循環マウントが機能するため、
    ほとんどのディストリビューションに同梱されているmkinitrdはtmpfs /tmpを正常に使用できます。

  2. 私が知らない方が多いと思います:-)

tmpfsには、サイズ変更のための3つのマウントオプションがあります。

サイズ: このtmpfsインスタンスに割り当てられるバイト数の制限。デフォルトは物理RAMの半分で、スワップはありません。 tmpfsインスタンスが大きすぎると、OOMハンドラがメモリを解放できないため、システムがデッドロックに陥ります。
ブロック数：サイズと同じですが、PAGE_CACHE_SIZE単位です。
nr_inodes:このインスタンスの最大 inode 数。デフォルトは、物理RAMページ数の半分、または（高域を持つシステムでは）lowmem RAMページ数の半分のいずれか小さい方です。

~から透明で巨大なページカーネル文書:

hugetlbfsの予約アプローチと比較して、透明なhugepageサポートは、未使用のすべてのメモリをキャッシュまたは他のリムーバブル（または取り外し不可能なエンティティ）として使用できるようにすることで、利用可能なメモリの有用性を最大化します。ユーザー・スペースが hugepage 割り当ての失敗を認識しないようにスケジュールする必要はありません。これにより、大きなページでページングやその他の高度なVM機能を利用できます。これを利用するためにアプリケーションを変更する必要はありません。

ただし、この機能を活用するようにアプリケーションをさらに最適化できます。たとえば、以前は malloc(4k) ごとに多数の mmap システムコールを防ぐように最適化されていました。現時点では、ユーザースペースの最適化は必須ではありません。khugepagedは、大容量メモリを処理するhugepage対応アプリケーションの場合でも、すでに長期ページ割り当てを処理できます。

いくつかの計算を行った後の新しいコメント：

HugePage サイズ: 2MB
使用された HugePages: なし/オフ、すべて 0 と表示されますが、上記の 2Mb に従って有効になります。
DirectMap4k: 8.03Gb
DirectMap2M: 16.5Gb
DirectMap1G: 2Gb

THSの最適化に関する上記の段落を使用すると、4kのmallocタスクを使用するアプリケーションでは8Gbのメモリを使用しますが、2Mのmallocを使用するアプリケーションは16.5Gbを要求したようです。 2M mallocを使用するアプリケーションは、2M部分をカーネルにオフロードし、HugePageサポートをエミュレートします。カーネルによって malloc が解放されるとメモリがシステムに解放されますが、大容量ページで tmpfs をマウントすると、システムが再起動されるまで完全なクリーンアップが行われないため、これは好ましい方法です。最後に、最も簡単なのは、2つのプログラムが開いて実行中で、1GBのmallocを要求することです。

知らない読者のために説明すると、mallocはメモリ割り当てを表すC言語の標準構造です。これらの計算は、DirectMappingとTHSの間のOP相関関係がおそらく正確であることを証明します。また、HUGEPAGE ONLY fsをインストールすると2MBの増分利得しか得られませんが、システムでTHSを使用してメモリを管理することはほとんど4kブロックで発生します。つまり、各malloc呼び出しは、使用のためにメモリ管理（2048 - 4）の観点からシステム2044kを節約することを意味します。他のプロセスによって。

おすすめ記事