問題タブ [memory-pressure]

ここでの目標は、Linux でメモリが不足している間、実行中のすべてのプロセスの実行可能コードをメモリに保持することです。Linux では、Qubes OS R4.0 Fedora 28 AppVM 内の 24000MB の最大 RAM を使用して、
即座に (1 秒) 高いメモリ負荷を引き起こし、OOM キラーをトリガーすることができます stress --vm-bytes $(awk '/MemAvailable/{printf "%d\n", $2 + 4000;}' < /proc/meminfo)k --vm-keep -m 4 --timeout 10s(コードはhereから)。EDIT4：おそらく関連していますが、言及するのを忘れていたのは、スワップが有効になっていない（つまりCONFIG_SWAP、設定されていない） という事実です

dmesg レポート:

興味深いのはactive_file:94 inactive_file:72、それらがキロバイト単位であり、非常に小さいことです。

ここでの問題は、メモリ不足の期間中に実行可能コードがディスクから再読み取りされ、ディスクのスラッシングが発生して OS がフリーズすることです。(ただし、上記の場合は 1 秒未満しか発生しません)

kernel に興味深いコードがあります:mm/vmscan.c

誰かがこれを に変更する方法を指摘できればgive them one more trip around the active list、give them infinite trips around the active list仕事は完了するはずです。それとも何か他の方法があるのでしょうか？

カスタム カーネルにパッチを適用してテストできます。アクティブな実行可能コードを常にメモリに保持するためにコードの何を変更すればよいかについてのノウハウがありません（実際には、ディスクのスラッシングを回避できると思います）。

編集:これまでに作業したことは次のとおりです (カーネル 4.18.5 の上に適用されます):

上記のコードでは、タブがスペースに変換されたため、github にも表示されます。（mirror1、mirror2）
上記のパッチをテストしました（現在4000MBの最大RAMで、以前より20G少ないです！）、OSを永久フリーズにディスクスラッシュすることが知られているFirefoxコンパイルでさえ、それはもう起こりません(oom-killer は、問題のあるプロセスをほぼ即座に強制終了しています)。また、上記のstressコマンドを使用すると、次の結果が得られます。

それactive_file:26925 inactive_file:76は、ほぼ 27 MB のアクティブなファイルです...
だから、これがどれほど良いかわかりません。実行可能ファイルだけでなく、すべてのアクティブなファイルをメモリに保持していますか? Firefoxのコンパイル中に、500メガのようなものを持っていましたActive(file)（ EDIT2 ：しかし、それによると： dmesgからcat /proc/meminfo|grep -F -- 'Active(file)'上記とは異なる値を示していますactive_file:!!!）、それはexes / libsだけだったのではないかと疑っています...
多分誰かが方法を提案できます実行可能コードのみを保持しますか
? (それがすでに起こっていない場合)

EDIT3:上記のパッチでは、(定期的に?)sudo sysctl vm.drop_caches=1古いメモリを解放するために実行する必要があるようです(? ) 。その後、もう一度実行すると、次のようになります: (22メガ) - 私は確信が持てません... stressactive_file:142281 inactive_file:0 isolated_file:0echo 1|sudo tee /proc/sys/vm/drop_cachesstressactive_file:22233 inactive_file:160 isolated_file:0

上記のパッチを適用しない場合の結果:こちら
上記のパッチを適用した場合の結果:こちら

免責事項 (後で追加): 以下の @jasonharper および @user2357112supportsMonica のコメントを考慮してコードを変更しました。まだメモリの問題があります。

次のコードを実行しています。

for ループのほとんどすべての反復で、1 秒あたり約 33 回の反復ですべてがスムーズに進みます。

ただし、まれに、ループがスタックして、かなりの数秒間メモリ不足が発生し始めることがあります。最終的に、特定の後の反復でカーネルが停止します。

random.sample()カーネルが停止する反復またはメモリ負荷の高い反復の 1 つに関連するインデックスからループを開始した場合 (したがって、何らかの形で結果的に をシフトするrandom.seed())、問題はなく、ループが通過するため、関連しているようです。他の高速反復と同様です。

ここにいくつかのスクリーンショットを添付します。