~から作家に学びました。:
OOM キラーは、現在のジョブが合理的な時間内に終了し、メモリが解放されることを望む場合にのみ、ジョブの終了を許可します。 (…)
上記のコア仮定を破るワークロードを構築することは難しくなく、OOM被害者がOOMで循環するのを待つ無停電状態でブロックされる可能性があるため、終了するには無限の時間がかかることがわかりました（例：萩テツオ）。ページアロケータ他のアクション（ロックなど）によってブロックされたイベント。
このパッチは、oomの被害者が所有する匿名メモリまたは交換されたメモリを先制的に取得しようとする専用のカーネルスレッド（oom_reaper）を導入することで、このロックの可能性を減らします。ただし、所有者が死んだときに追加のメモリが必要ないとします。ユーザースペースから追い出されました。
簡単に言えば、oom_reaperカーネルスレッドは、oom_killerが不適切な決定を下す可能性を減らすように設計されています。
私が知る限りRHEL 8ドキュメント:
/proc/sys/vm/panic_on_oomファイルには、メモリ不足（OOM）の動作を制御するスイッチイン値が含まれています。ファイルに 1 が含まれる場合、カーネルは OOM によってパニックが発生し、期待どおりに動作を停止します。
デフォルトは0で、システムがOOM状態にあるときにカーネルにoom_killer関数を呼び出すように指示します。
簡単に言うと：vm.panic_on_oom = 1 OOMステータスはoom_killerの起動をトリガーしません。
したがって、論理的にoom_reaper松葉杖は必要ありません。
ただし、oom_reaperは、vm.panic_on_oomの値に関係なく、システムが初期化されると（linux-5.4で）起動します。
なぜ？私が逃したものはありますか？殺人者が解雇されなくてもoom_reaperが必要な理由はありますか？そうでない場合、vm.panic_on_oom = 1のときにoom_reaperが起動しないようにする方法は？
注1：もちろん私は出身です。コードを読むCONFIG_MMUが設定されていない場合は構築されませんが、私のシステムでは明らかにオプションではありません。
ベストアンサー1
「OOMキラー」など様々なものがあります。カーネルの統合 最後の手段 OOM キラー機能を無効にしました。これは起動されたデーモンとは無関係です。
長年にわたり、多くのシステムユーティリティは、システムが機能しなくなる前にメモリが爆発するプロセスを終了するよりスマートな方法を実装してきました。おそらくシステムOOMキラー（実際に作者を何度も手に入れた）を扱っているでしょう。
バラよりman oomd.conf設定方法を学ぶsystemd-oomd。実際に無効にしたい極端な場合（なぜ？システムを回復できないようにしました！）他のsystemctl disable xyz.service。
（ああ、同じプロセス名を持つCOTS NASボックスをターゲットにするいくつかのマルウェアもありますが、oom_reaperおそらくあなたが扱っているわけではありません。）