tmpfs と shm の間に違いはありません。 tmpfs は、shm の新しい名前です。 shm は、SHAredMemory の略です。
参照:Linux tmpfs。
今日でも 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 が /dev/shm にマウントされていることが想定されています。
POSIX 共有メモリ (shm_open、shm_unlink)。以下を追加
/etc/fstab への行でこれを処理する必要があります:
tmpfs /dev/shm tmpfs デフォルト 0 0
必要に応じて、tmpfs をマウントする予定のディレクトリを忘れずに作成してください。
このマウントはではありません SYSV 共有メモリに必要です。内部
マウントはそのために使用されます。 (2.3 カーネル バージョンでは、
SYSV を使用するには、tmpfs の前身 (shm fs) をマウントする必要があります
共有メモリ)
3) 一部の人々 (私を含む) は、マウントするのが非常に便利だと感じています。
例えば/tmp および /var/tmp にあり、大きなスワップ パーティションがあります。そしていま
tmpfs ファイルのループ マウントは機能するため、ほとんどの場合 mkinitrd が出荷されます。
ディストリビューションは tmpfs /tmp で成功するはずです。
4) そして、おそらく私が知らないことはもっとたくさんあります :-)
tmpfs には、サイジングのための 3 つのマウント オプションがあります:
サイズ: この tmpfs インスタンスに割り当てられたバイト数の制限。デフォルトは、スワップなしの物理 RAM の半分です。 tmpfs インスタンスのサイズが大きすぎると、OOM ハンドラがそのメモリを解放できないため、マシンがデッドロックします。
nr_blocks: サイズと同じですが、PAGE_CACHE_SIZE のブロックです。
nr_inodes: このインスタンスの inode の最大数。デフォルトは、物理 RAM ページ数の半分、または (highmem を搭載したマシンでは) lowmem RAM ページ数のいずれか少ない方です。
Transparent Hugepage Kernel Doc から:
<ブロック引用>透過的ヒュージページ サポートは、未使用のすべてのメモリをキャッシュまたはその他の可動 (または可動でないエンティティ) として使用できるようにすることで、hugetlbfs の予約アプローチと比較して、空きメモリの有用性を最大化します。 hugepageallocation の失敗がユーザーランドから目立つのを防ぐための予約は必要ありません。これにより、ページングおよび他のすべての高度な VM 機能を hugepage で使用できるようになります。アプリケーションがそれを利用するために変更を加える必要はありません。
ただし、アプリケーションをさらに最適化して、この機能を利用することができます。たとえば、malloc(4k) ごとに大量の mmap システム コールを回避するようにアプリケーションを最適化するなどです。ユーザーランドの最適化は必須ではなく、khugepaged はすでに、大量のメモリを扱うヒュージページを認識しないアプリケーションであっても、長寿命のページ割り当てを処理できます。
いくつかの計算を行った後の新しいコメント:
HugePage サイズ:2MB
使用される HugePages:なし/オフ、すべて 0 で示されますが、上記の 2Mb に従って有効になっています。
DirectMap4k:8.03Gb
DirectMap2M:16.5Gb
DirectMap1G:2GB
THS の最適化に関する上記の段落を使用すると、メモリの 8Gb が 4k の malloc を使用して動作するアプリケーションによって使用され、16.5Gb が 2M の malloc を使用するアプリケーションによって要求されているように見えます。 2M の malloc を使用するアプリケーションは、2M セクションをカーネルにオフロードすることで、HugePage サポートを模倣しています。カーネルによって malloc が解放されると、メモリがシステムに解放されるのに対し、hugepage を使用して tmpfs をマウントすると、システムが再起動されるまで完全なクリーニングが行われないため、これが推奨される方法です。最後に、1Gb の malloc を要求する 2 つのプログラムを開いて実行しているとします。
malloc が C の標準構造であり、Memory ALLOCation の略であることを知らない読者のために説明します。これらの計算は、DirectMapping と THS の間の OP の相関関係が正しい可能性があることの証明として機能します。また、HUGEPAGE ONLY fs をマウントしても 2MB のインクリメントしか得られないことに注意してください。一方、THS を使用してシステムにメモリを管理させると、ほとんどの場合 4k ブロックで発生します。これは、メモリ管理の観点から、すべての malloc 呼び出しがシステムを節約することを意味します 2044k(2048 - 4 ) 他のプロセスを使用するため。
「DirectMap」の問題に対処するには:カーネルには、各ユーザー プロセスに割り当てられた仮想マッピングとは別に、物理メモリの線形 (「直接」) マッピングがあります。
カーネルは、このマッピングに可能な最大のページを使用して、TLB の負荷を軽減します。
DirectMap1G は、CPU が 1Gb ページをサポートしている場合 (Barcelona 以降。一部の仮想環境では無効になっています) に表示され、カーネルで有効になっている場合 - デフォルトは 2.6.29+ でオンになっています。
shm に違いはありません と tmpfs (実際には、tmpfs 以前の shmfs の新しい名前だけです ）。 hugetlbfs tmpfs です カーネルの巨大なページからスペースを割り当て、追加の構成余裕が必要なベースのファイルシステム (これを使用する方法は、Documentation/vm/hugetlbpage.txt で説明されています)。