次のシナリオを考えてみましょう。あなたは一つ持っています。遅い読み取り専用メディア（たとえば、書き込み禁止のサムドライブ、CD / DVDなど）（Live CD自体ではなく通常のバージョン）からLinuxをマウントし、他の種類のストレージデバイスのないコンピュータで使用してください。 USB2なので遅いです。ルートファイルシステムは、ログや他の多くの一時タスクに「書き込み」できるようにoverlayfsとしてマウントされますが、すべての書き込みはRAM（tmpfs upperdir）に書き込まれます。これはライブ展開の非常に一般的なシナリオです。
他の形式のリポジトリがないため、スワップはzramにマウントされます。そのため、Linux は交換することを決めた場合、そのページを圧縮し、まだ RAM に保存しますが、少なくとも圧縮されます。ほとんどのアプリケーションのRAMは簡単に圧縮されるため、これは実際には良いです（RAMは通常「高速」という意味なので、データと非常に重複します）。これはアプリケーションメモリには機能しますが、tmpfsには機能しません。
問題は次のとおりです。 zramは早く、信じられないい。一方、Thumbドライブは遅いです。 20MiB/sだとしましょう。これは比較すると本当に遅い速度です。ここでは、問題とカーネルが正しい操作を実行していない理由を確認できます。
ちなみに、この質問はいいえ繰り返しTMPFS内のファイルを交換する可能性を高める方法。質問はほぼ同じですが、その質問に対する答えは満足できません。申し訳ありません。カーネルは次のようにする必要がありますいいえ何があっても自分で「正しいこと」をしてください。賢いデザインした人がそうでした。私は人々が状況を理解していないし、自分がよりよく知っていると思うのが好きではありません。彼らは一般的な状況を満たしています。これがLinuxが適応力に優れた理由です。どんなに賢くても、自分が何をするか予測できないからです。
たとえば、設定できます。仮想マシンの切り替え可能性（/proc/sys/vm/swappiness）を100に設定します。これは、アプリケーションメモリを積極的に交換し、ファイルキャッシュを保存するように指示します。このオプションは素晴らしいですが、残念ながらこれはすべてではありません。
優先順位にしたいファイルキャッシュの保持スワップを処理するときは、他のどのRAM使用量よりも多くのRAMを使用します。これは、ファイルキャッシュを削除すると、より遅い20MiB / sドライブから再読み込みする必要があるためです。たくさんzramに置き換えるよりも遅いです。 vm.swappinessはアプリケーションでは機能しますが、tmpfsでは機能しません。
tmpfsはページキャッシュとしてマウントされるため、ファイルキャッシュと優先順位は同じです。 tmpfsからファイルを読み取ると、以前のファイルキャッシュエントリ（最も最近使用されたエントリ）よりも優先されます。しかし、これは迷惑です、カーネルは明らかです。確かにここで正しいことをしてください。ドライブからデータを読み取るのは非常に遅いので、tmpfsをzramに置き換えることが「最近使用された」ファイルキャッシュよりもはるかに優れていることを考慮する必要があります。
したがって、ファイルキャッシュよりもtmpfsでより頻繁に置き換えるように明示的に指示する必要があります。つまり、tmpfsよりもファイルキャッシュを頻繁に保存する必要があります。 /proc/sys/vm には多くのオプションがありますが、関連するオプションは見つかりません。本当に残念です。
これが失敗した場合、一部のデバイス/ドライバが他のデバイス/ドライバよりもはるかに遅く、他のデバイスよりもキャッシュを予約することを好む必要があるとカーネルに通知する方法はありますか？ tmpfsとzramは高速です。サムドライブはそうではありません。カーネルにこの情報を伝えることはできますか？
すべてのドライブを同じように扱うと、独自に「正しい操作」を実行することはできません。 tmpfs を zram などの高速ドライブに置き換えるのは、最近 tmpfs を使用しても、遅いドライブからキャッシュを削除するよりもはるかに高速です。
使用可能なメモリが不足している場合は、スワップの可能性によってアプリケーションのメモリスワップを開始するか（良い）、古いファイルキャッシュを削除します（悪い）。結局のところ、このファイルをもう一度読むと非常に遅くなります。一部のtmpfを交換して（最近使用した場合でも）、再読み込みよりもはるかに遅いです。 zramがはるかに速いからです。
ベストアンサー1
増加する交換性値を使用すると、カーネルがより多くのtmpfsページを交換し、スワッピングをサポートしていない他のファイルシステムからキャッシュされたページを削除する意思が少なくなります。
zramスワップはサムドライブよりも高速なので、理想的にはスワップ性を100以上に増やすことをお勧めします。これはカーネルバージョン5.8以降でのみ可能です。 Linux 5.8では、スワップ性を最大200に設定できます。
zram や zswap などのメモリスワップでは、100 以上の値を考慮できます。たとえば、スワップデバイスのランダムIOがファイルシステムのIOよりも平均2倍速い場合、スワップ可能性は133（x + 2x = 200、2x = 133.33）でなければなりません。
追加読書
tmpfs は他のスワップ可能なメモリのように扱われます。
カーネルコミットを見る"vmscan：LRUリストを匿名およびファイルセットに分割する"——
LRUリストを2つの部分に分割します。 1つは物理ファイルシステムでサポートされているページ（「ファイル」）、もう1つはメモリとスワップでサポートされているページ（「匿名」）です。後者には tmpfs が含まれます。
- そしてコードlinux-4.16/mm/vmscan.c:2108-
/*
* Determine how aggressively the anon and file LRU lists should be
* scanned. The relative value of each set of LRU lists is determined
* by looking at the fraction of the pages scanned we did rotate back
* onto the active list instead of evict.
*
* nr[0] = anon inactive pages to scan; nr[1] = anon active pages to scan
* nr[2] = file inactive pages to scan; nr[3] = file active pages to scan
*/
static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,
struct scan_control *sc, unsigned long *nr,
unsigned long *lru_pages)
{
int swappiness = mem_cgroup_swappiness(memcg);
...
/*
* With swappiness at 100, anonymous and file have the same priority.
* This scanning priority is essentially the inverse of IO cost.
*/
anon_prio = swappiness;
file_prio = 200 - anon_prio;
Linux 5.8では、次のことを許可します。交換性最大値は200です。
mm：交換を許可し、ファイルワークセットよりも匿名のリサイクルを優先します。
高速ランダムIOデバイス（SSD、PMEM）およびメモリ内スワップデバイス（zswapなど）の出現により、スワッピングはファイルシステムよりはるかに高速になり、ファイルシステムキャッシュをスラッシングするよりもスワッピングが優れています。
スワップ設定範囲を設定して、この状況を反映するようにスワップ機能（ページキャッシュとスワップサポートページ間のキャッシュミスのおおよその相対IOコストを定義）を設定できます。
これはLinux 5.8で提供される一連のパッチの一部です。以前のバージョンでは、Linuxは「主にページキャッシュを使用し、仮想マシンが深刻なメモリ不足に遭遇するまでスワッピングを延期しました」これは、「アルゴリズムの開発中に回転するドライブのナビゲーションコストが高いためです。これは、バグが過度に積極的なスワッピング（主にランダムIO）によって急速に停止する可能性があることを意味します。」
このシリーズはこの問題を解決することを目的としています。コミット（「a528910e12ec mm：Flutter検出によるファイルキャッシュのサイズ変更」）の後、エラーIOを正確に追跡できるようになりました。これはエラーページを回復するための究極のコストです。これにより、不要なスワップストームを回避しながら、キャッシュスラッシング中に匿名メモリをより積極的にチェックするIOコストベースのバランシングモデルを使用できます。
これらのパッチは、各リストの失敗率にスワップデバイスとファイルシステム間の相対的なIOコスト（スワップ性）を掛けたLRUバランスに基づいているため、発生するIOコストを最小限に抑えるように再生が最適化されます。