Linuxのコンテキスト切り替え頻度を変更するにはどうすればよいですか？
Linux（linaro、ubuntu、debian）のコンテキスト切り替え頻度を変更するにはどうすればよいですか？
応答性の低いシステムを効率的なシステムにトレードオフしても大丈夫です。
EDIT1：私はできるだけ速く実行したいメインプロセス（1秒あたりの最大クロックサイクル数）を持っているので、コンテキストスイッチの頻度を減らす（=タイムスライスを増やす）ことを考えました。問題はそれをどのように行うかであり、大きな影響があるでしょうか。コンテキストスイッチのコストを計算できますか？つまり、タイムスライスを2増やした場合、私が気にするメインプロセスのパフォーマンスの向上率は％になりますか？
タスクが特定のCPUで時間を要求するonlyプロセスである場合、タスク間のコンテキスト切り替えはありません:-)。しかし、CPUはまだ中断されている可能性があり、コンテキストがカーネルに切り替えられて戻されます。考えられる原因の1つは、プリエンプションタイマーです。このCPUで実行する別のタスクがあるかどうかを確認しています...
Linuxcan理由がない場合、CPUでプリエンプションタイマー割り込みを生成しないようにすることができます。 CONFIG_NO_HZ_FULLを参照してください。この機能を使用するには、カーネルの構築時に有効にする必要があり、およびブートオプションを使用して有効にする必要があります。
- https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
- https://lwn.net/Articles/549580/ "3.10での（ほぼ）フルティックレス操作"
デフォルトでは、どのCPUも適応ティックCPUではありません。 "nohz_full ="ブートパラメーターは、適応ティックCPUを指定します。たとえば、「nohz_full = 1,6-8」は、CPU 1、6、7、および8が適応ティックCPUであることを示しています。すべてのCPUをアダプティブティックCPUとしてマークすることは禁止されていることに注意してください[...]
LWN.netは、「Ingo Molnarによると、CPUの時間の1％も節約される」と適応ティックCPUについて述べています。カーネルのドキュメントには、これには6つの異なるコストがあり、「既知の問題」のリストもあります。
このゲインは比較的小さく、特に、この回答で参照されているように、複数のタスク間のコンテキスト切り替えの頻度を減らす潜在的なスループットのゲインと比較すると、 Linux CPUスケジューラで使用されるタイムスライスの長さを変更する方法？
細字：これらの測定は、Spectre、Meltdown、KPTI、およびx86 ASIDのサポート以前のものでした: 。また、これらはいくぶん古いハードウェアにも適用されると思います。特定のカーネルバージョンとハードウェアで変更されました...カーネルを非常に頻繁に呼び出すソフトウェアを除いて、PTIは主にASIDによって軽減されると考えられていました。主な例はデータベースです。 。
元のRFCパッチにおけるMolnarの希望は、時間の経過とともに、「ほとんどのLinuxディストリビューションで有効になる可能性が高い」ということでした。 Fedora 28はNO_HZ_FULLサポート付きでビルドされたデフォルトのカーネルを提供していることに気づきました。ただし、Debian 9ではサポートされていません。
最近では、Linux v4.17 ---（nohz_full CPUから残りの1 Hzタイマーティックを削除 。スループットへの影響はかなり小さいと思います:-)が、CPUに複数の実行可能なプロセスがある場合のNO_HZ_FULLのメリットのステータスを追跡しようとしています-
0 Hzに達したら、nr_runningに応じて、sched_latency制約が必要とする頻度でビジータスクを本質的に中断することにより、nr_running> = 2から定期的なティックの仮定を削除することもできます-nr_runningに応じて、4〜40ミリ秒ごと。
これは、v2.6.25-rc1で別のより正確なティックバックを使用してプリエンプションがすでに開始されているため、少し混乱します commit 8f4d37ec073c、 "sched：high-res preemption tick" 。同じLWN.net記事のこのコメントで見つかりました： https://lwn.net/Articles/549754/ ）。