[linux][自分用メモ] cpufreqのガバナーにschedutilというのが増えたことを今さら知った。

前振り
- Linuxのgovernor
本題
LKMLで追加されたときのアナウンス
lwn.netで取り上げられた時の記事
どういうものか
気になった記事

前振り

Linux環境で普通に使用しているとき、特に理由がない限りはcpufreqを使用し、CPUの使用状況に合わせてgovernorを設定していると思います。

現在主に使用されているgovernorは以下のものがあり、特に ondemandが使用されていると思います。

interactive
conservative
userspace
powersave
ondemand
performance

cpufreq_ondemand
Ondemand ガバナーは動的なガバナーです。システム負荷が大きい時は、CPU は最高クロック周波数を実現し、システムがアイドル状態の時には、CPU は最低クロック周波数を実現します。これにより、システム負荷に対してシステムは電力消費量を適宜調節できますが、そうすることで 周波数変換の間の遅延 が発生してしまいます。そのため、システムがアイドル状態と高負荷の間で頻繁に替わりすぎると、遅延により Ondemand ガバナーが実現できるパフォーマンスおよび/または節電の利点が少なくなる恐れがあります。
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/power_management_guide/cpufreq_governors

  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3                         
  maximum transition latency: 78.0 us.
  hardware limits: 408 MHz - 1.51 GHz
  available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.30 GHz, 1.39 GHz, 1.51 GHz
  available cpufreq governors: interactive, conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 600 MHz and 1.39 GHz.                                 
                  The governor "ondemand" may decide which speed to use                           
                  within this range.
  current CPU frequency is 1.30 GHz (asserted by call to hardware).                               
  cpufreq stats: 408 MHz:0.00%, 600 MHz:83.58%, 816 MHz:0.00%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.30 GHz:16.42%, 1.39 GHz:0.00%, 1.51GHz:0.00%  (228735)

governorの説明については、RedHatのドキュメントに詳しく解説が掲載されています。

Linuxのgovernor

3.2. CPUfreq Red Hat Enterprise Linux 7 | Red Hat Customer Portal

Access Red Hat’s knowledge, guidance, and support through your subscription.

本題

今まで使用されているCPU governorは、 CPU周波数の変更が実際に必要とされるよりも頻繁に呼び出され、またCPU周波数の選択を更新するよりも頻繁に呼び出されるため遅延が生じてしまい応答性が悪化する、という問題があったそうです。

それらを改善するための方策として、今回の”schedutil”というgovernorが追加された、ということのようです。

LKMLで追加されたときのアナウンス

LKML: "Rafael J. Wysocki": [PATCH v6 7/7][Update] cpufreq: schedutil: New governor based on scheduler utilization data

lwn.netで取り上げられた時の記事

Improvements in CPU frequency management [LWN.net]

どういうものか

The new governor is relatively simple.
The frequency selection formula used by it depends on whether or not
the utilization is frequency-invariant. In the frequency-invariant
case the new CPU frequency is given by
next_freq = 1.25 * max_freq * util / max
where util and max are the last two arguments of cpufreq_update_util().
In turn, if util is not frequency-invariant, the maximum frequency in
the above formula is replaced with the current frequency of the CPU:
next_freq = 1.25 * curr_freq * util / max
The coefficient 1.25 corresponds to the frequency tipping point at
(util / max) = 0.8.
All of the computations are carried out in the utilization update
handlers provided by the new governor. One of those handlers is
used for cpufreq policies shared between multiple CPUs and the other
one is for policies with one CPU only (and therefore it doesn’t need
to use any extra synchronization means).
https://lkml.org/lkml/2016/3/17/420

ちなみにこの変更、linux kernel 4.6でマージされてたんですね・・・

OSのスケジューラであるtickと同期されなくなりそのことでintel_pstateの正確な状態の検出が可能になったこと、高速な周波数スイッチングのためにfast_swithch()が実装され無駄にスリープ状態に移行しないようになったこと、これらにより応答性が改善されスケジューラから細かい制御が出来るようになったことがメリットだ、とされています。

最終的には、リアルタイムタスク、deadlineタスク、インタラクティブタスク、およびバックグラウンドタスクに正しく応答する必要があり、これらはすべて、スケジューラーがすでに処理しなければならない概念です。したがって、cpufreqがそれらの処理も学習できると期待し、governorを一本化することが目標のようです。

まぁイマイチドキュメントを読み切れていないので、現在主流の”ondemand”と比較し、現在の環境でもどれほどメリットがあるのか理解しきれていません。

思ったよりもCPU周波数が下がらなくなったのは確認できているのですが、これがどれほどパフォーマンスに影響されているのか客観的に測定出来ていないのもあるかもしれませんが・・・

気になった記事

Linux Hardware Reviews & Performance Benchmarks, Open-Source News - Phoronix

Phoronix is the leading technology website for Linux hardware reviews, open-source news, Linux benchmarks, open-source b...