カーネルパラメータを簡単に変更してsysctlから永久に作成できます。/etc/sysctl.dしかし、デフォルト値などのデフォルトのカーネルパラメータを変更する簡単な方法はありますか？VM切り替え可能性=60カーネルのコンパイル段階中。
カーネルのソースコードに次のようなものがあることがわかりました。mm/vmscan.c以下を含むファイル：
(...)
int vm_swappiness = 60
(...)
パラメータは、多くのソースファイルに存在するこれらのパラメータを変更して変更する正しい方法ですか、それとも変更したいいくつかのユーザーファイルを生成することは可能ですか？モジュールも同様です。モジュールに次のオプションを追加/変更するには、モジュールソースファイルを編集する必要がありますか？/etc/modprobe.d:
options modulename parameter=value
要約すると、コンパイル段階でいくつかのカーネルのデフォルトパラメータといくつかのモジュールオプションを変更したいと思います。
ベストアンサー1
sysctl設定で実際に調整できるカーネルパラメータについて、カーネルのソースコードにパッチを適用してこれらの値を変更することにはほとんど興味がありません。
次のカーネルアップデートでジョブを再実行する必要があり、パッチを実行する場合は、パッチが正しく適用されていることを確認する必要があります。通過実際には、いくつかの異なるデフォルト値を設定するだけです！
ユーザー空間に絶対に公開されないハードコーディングされた値について通常、これを修正することに興味がないか、リスクが高いと仮定できます。これに依存する他のすべてのパラメータに与える影響を詳しく調べる必要はありません。可能ですか？関連カーネルのソースコードに積極的に貢献している人ではない場合は、次のように言いたいと思います。いいえ！
ただし、ユーザースペースに必ずしも公開されていないカーネル調整可能アイテムの場合は、そうすることに興味があるかもしれません。カーネル構成オプションによって異なります。
スケジューラ調整可能な項目を例に挙げます。sched_latency_nsCONFIG_SCHED_DEBUG が設定されている場合にのみユーザー空間に公開されます。
この構成設定を使用すると、オーバーヘッドが発生します。
したがって、待ち時間を短縮し、スケジューラを処理するときにオーバーヘッドに対応することは論理的に一貫性がありません。
非常に特定のケースでは、デバッグコードを無効にして値をハードコーディングすることがデータを変更する唯一の方法になるため、一貫して見えることがあります。
もちろん、この方法で作業を実行すると、カーネルがまだテストしていない値を強制的に適用し、潜在的にその値を破棄してデバッグを妨げる可能性があることを知っています。 （上記の例に関連して...実際に次のようにプレイすると、不快な結果が得られます。sched_wakeup_grinderity_ns値。 ）
もちろん、次にカーネルを更新するときは、すべてのタスクを再実行する必要があること、カーネル変更時の設定の影響を理解する必要があること、つまりカーネルについて非常に深く理解する必要があることを知っており、少なくとも変更ログを注意深く読んでください。してください。
だから、「カーネルパラメータを変更するのは正しいですか？」？私が言うだろう…専用カーネルデバッグ機能がサポートする専用sysctl方式で設定されたチューナブルを使用する前に、実際にシステムを広範囲にテストしていない限り、いいえ！当然じゃない！でも、Linus自身もそうしません。
それ以外にも、個人的な経験から見ると、スケジューラの調整可能性（デバッグコードやその他の統計の無効化）に準拠した方法で、客観的に確認または関連性を確認するために使用できるデータがゼロであることを認める必要があります。私のいたずらを…