Linuxコンテキストスイッチの頻度を変更する方法は？

Linux（linaro、ubuntu、debian）のコンテキスト切り替え頻度を変更するにはどうすればよいですか？

応答性の低いシステムをより効率的なシステムにトレードオフしても大丈夫です。

EDIT1：可能な限り高速に実行するメインプロセス（1秒あたりの最大クロックサイクル）があるため、コンテキストスイッチの頻度を減らす（=タイムスライスを増やす）と考えました。問題はそれをどのように行うかであり、重大な効果があるでしょう。コンテキストスイッチのコストを計算できますか？つまり、タイムスライスを2ずつ増やした場合、推定できるのは、関心のあるメインプロセスのパフォーマンスの向上（％）です。

タスクが特定のCPUで時間を要求する唯一のプロセスである場合、タスク間のコンテキストスイッチはありません:-)。ただし、CPUがまだ中断されている可能性があり、コンテキストスイッチがカーネルに切り替わって戻っています。考えられる原因の1つは、このCPUで実行する別のタスクがあるかどうかをチェックするプリエンプションタイマーです...

Linux は、理由がない場合に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は、適応ティックCPUの場合、「Ingo Molnarによると、CPUの時間の1％が節約される」と述べています。カーネル文書には、これには6つの異なるコストがあり、「既知の問題」のリストもあると書かれています。

この回答は、この回答で参照されているように、複数のタスク間のコンテキスト切り替えの頻度を減らす潜在的なスループットの向上と比較して、比較的小さいです：Linux CPUスケジューラーによって使用されるタイムスライスの長さを変更するには？

小さい活字：これらの測定は、Spectre、Meltdown、KPTI、およびx86 ASIDサポートよりも前に行われます:-(そして、それらはやや古いハードウェアにも適用されると思います。特定のカーネルバージョンとハードウェアを変更しました... PTIは、主にデータベースなどのカーネルを頻繁に呼び出すソフトウェアを除き、主にASIDによって緩和されるはずでしたが、数値についてはよくわかりません。 。

元のRFCパッチでのMolnarの希望は、時間とともに「ほとんどのLinuxディストリビューションで有効になる可能性が高い」ことでした。Fedora 28は、NO_HZ_FULLサポート付きでビルドされたデフォルトのカーネルを提供しています。ただし、Debian 9はサポートしていません。

さらに最近では、Linux v4.17 はnohz_fullCPU から残留1 Hzタイマーティックを削除します。スループットへの影響は非常に小さいと思います:-)がNO_HZ_FULL、CPUに複数の実行可能なプロセスがある場合の利点の状況を追跡しようとしています-

0 Hzに達すると、sched_latency制約が必要とする頻度でのみ、基本的にビジーなタスクを中断することにより、nr_running> = 2から周期ティックの仮定を削除できます。nr_runningに応じて4〜40ミリ秒に1回。

これは、すでにv2.6.25-RC1で別の、より正確なチックバックを使用して開始プリエンプションとして混乱ビットで、8f4d37ec073cをコミットし、「schedの高解像度プリエンプションダニ」。同じLWN.net記事（https://lwn.net/Articles/549754/）でこのコメントを介して見つかりました。