Googleのエンジニア、Qais Yousef氏は日曜、Linuxカーネルのデフォルトのタイマー周波数を250Hzから1000Hzに増やすことを提案するパッチをリリースした。 Google のエンジニアは、現在の Linux カーネルのデフォルト周波数が、不正確なタイム スライス、負荷分散の遅延、統計更新の遅延、その他の関連問題など、スケジューラの決定に問題を引き起こす可能性があると考えています。 QaisYousef は、カーネルがデフォルトの周波数 1000Hz を採用する方が良いと考えています。

「Android やデスクトップ システムなどの一般的な画面構成は 120 Hz です。これにより、タスクの処理時間は 8 ミリ秒になります。4 ミリ秒はその半分の時間であり、ウェイクアップで非常に適切な決定を下す負担が必要以上に重くなります。また、システムを効率的に利用して最適なパフォーマンス/ワットを維持することも難しくなります。たとえば、DVFS ヘッドルームを TICK の関数として定義しようとします。これは、統計を更新するための最悪のシナリオを定義するためです。TICK が大きいほど、パフォーマンスに影響を与えないようにしたい場合は、周波数を積極的に設定しすぎますが、タスクがすべてのフラグメントを使い果たさない場合は、より低い周波数を使用して電力を節約する機会を失います。

一般に、ワークロードの期限は短くなっていますが、これは UI パイプラインに限ったことではありません。

HZ_250 は、バッテリーを不必要に消耗させる可能性のある頻繁な TICK を好まないデバイスのバッテリー電力とのトレードオフとしてのデフォルト設定だと思います。しかし、私の理解によれば、現在の NOHZ の状況はこれらの懸念を軽減するのに十分であるはずです。最近追加された RCU_LAZY は、アイドル シナリオでより長い TICK を維持するのにさらに役立ちます。

Saravana が私に指摘したように、TICK を長くすると、タイマーの凝集性が間接的に向上します。つまり、頻繁なタイミングを必要とするドライバー/タスクの問題が隠蔽され、より深いアイドル状態への移行を防ぐことができます (多くのシステムでは、4ms はより深いアイドル状態への移行を可能にする高い値です)。しかし、これがこれらのドライバー/タスクの問題であると主張することもできます。

TICK が速いと出力も高くなる可能性がありますが、それは TICK アクティビティによるものではありません。システムの応答性は (予想通り) より高く、より高い周波数での滞留は、誤って低い周波数でスタックしてしまうため、より高くなることが予想されます。 [1] のシリーズは、スケジューラーによる応答速度の処理を改善し、適切な応答をオプトアウトするなど、ニーズに合わせた方法をユーザー/アプリケーションに提供することを試みています (上記のシリーズでは、ramup_multiplier は 0)。

Linux カーネル タイマーの頻度は、長い間議論と異なる意見の原因となってきました。しかし現在、コアのデフォルト周波数は 250Hz ではなく 1000Hz になっており、これは論理的であるように思えます。

デフォルトの頻度を変更するパッチがレビュー/ディスカッションのために提出されています。