最近、さまざまな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/meminfo および / proc/cpuinfo のフルテキストバージョンがあります)
上記で何が起こっているのですか? _hugepages?
_を既に割り当てていますかDirectMap
メモリページと_hugepages?
_の間に違いはありますか
Update@Gillesからの微調整の後、4行追加しましたが、違いがあるように見えますが、聞いたことがないDirectMap
それを引く前にtail
昨日...多分DMI
か何か?
もう少しだけ...
hugepages
の試みで成功せず、任意のイメージファイルのハードディスクバックアップを想定すると、_tmpfs?
_からループをマウントするリスクは何ですか私のファイルシステムはswapped
最悪のシナリオですか? tmpfs
はマウントされたファイルシステムキャッシュです-マウントされたループファイルをメモリから圧迫することはできますか?これを回避するために私ができる緩和策はありますか?
最後に、正確には_shm,
_とは何ですか? hugepages
または_tmpfs?
_とどのように異なる、または含まれていますか?
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
引用:
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つのマウントオプションがあります。
size:このtmpfsインスタンスに割り当てられたバイトの制限。デフォルトは物理の半分ですRAM swapなし。tmpfsインスタンスのサイズを大きくすると、OOMハンドラーがそのメモリを解放できないため、マシンはデッドロックします。
nr_blocks:サイズと同じですが、PAGE_CACHE_SIZEのブロック単位です。
nr_inodes:このインスタンスのiノードの最大数。デフォルトは、物理的な数の半分ですRAM=ページ、または(highmemのあるマシンでは)lowmemの数RAMページのいずれか低い方。
Transparent Hugepage Kernel Docから:
トランスペアレントヒュージページサポートは、hugetlbfsの予約アプローチと比較して、未使用のすべてのメモリをキャッシュまたは他の移動可能な(または移動できないエンティティ)として使用できるようにすることで、空きメモリの有用性を最大化します。 hugepage割り当ての失敗がユーザーランドから気付くのを防ぐために予約する必要はありません。ページングとその他すべての高度なVM=機能をhugepagesで利用できるようにします。アプリケーションがそれを利用するための変更は必要ありません。
ただし、アプリケーションをさらに最適化して、この機能を利用することもできます。たとえば、すべてのmalloc(4k)に対するmmapシステムコールのフラッドを回避するために、以前に最適化されています。ユーザーランドの最適化は必須ではなく、khugepagedは、大量のメモリを処理するhugepage非対応アプリケーションの場合でも、すでに存続期間の長いページ割り当てを処理できます。
いくつかの計算を行った後の新しいコメント:
HugePageサイズ:2MB
HugePages Used:None/Off、すべて0で示されるが、上記の2Mbに従って有効。
DirectMap4k:8.03Gb
DirectMap2M:16.5Gb
DirectMap1G:2Gb
THSでの最適化に関する上記の段落を使用すると、メモリの8Gbが4kのmallocs、16.5Gbを使用して動作するアプリケーションによって使用されており、2Mのmallocsを使用するアプリケーションによって要求されているようです。 2Mのmallocを使用するアプリケーションは、2Mセクションをカーネルにオフロードすることにより、HugePageサポートを模倣しています。これは推奨される方法です。mallocがカーネルによって解放されると、メモリがシステムに解放されます。一方、hugepageを使用してtmpfsをマウントしても、システムを再起動するまで完全なクリーニングは行われません。最後に、簡単なのは、1Gbのmallocを要求する2つのプログラムを開いて実行していることです。
あなたが読んでいる人にとって、mallocはCの標準構造であり、Memory ALLOCationを表しています。これらの計算は、DirectMappingとTHSの間のOPの相関がおそらく正しいことの証明として役立ちます。また、HUGEPAGE ONLY fsをマウントすると、2MBの増分でのみゲインが得られますが、THSを使用してシステムにメモリを管理させると、ほとんどの場合4kブロックで発生します。 )使用する他のプロセスの場合。
「DirectMap」の問題に対処するには、カーネルには 物理メモリの線形(「直接」)マッピング があり、各ユーザープロセスに割り当てられた仮想マッピングとは別です。
カーネルは、このマッピングに可能な限り最大のページを使用して、TLBプレッシャーを削減します。
DirectMap1Gは、CPUが1Gbページ(バルセロナ以降、一部の仮想環境では無効になっている)をサポートしている場合、およびカーネルで有効になっている場合に表示されます-2.6.29以降ではデフォルトです。
shm
とtmpfs
には違いはありません(実際、tmpfs
は以前のshmfs
の新しい名前にすぎません)。 hugetlbfs
はtmpfs
ベースのファイルシステムであり、カーネルの巨大なページからスペースを割り当て、追加の設定が必要です(これの使用方法は Documentation/vm/hugetlbpage.txtで説明されています) )。