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

2019-09-14 13:45:50AIX、UNIX、LinuxCPU, CPU frequency management, cpufreq, governor, schedutil

前振り

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

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

Linuxのgovernor

本題

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

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

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

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

どういうものか

POINT

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

気になった記事

この記事を書いた人

kometchtech

うつ病を患いながら、IT業界の末席にいるおっさんエンジニア。科学計算をしたことがないのに、HPC分野にお邪魔している。

興味のある分野で学習したことをblogにまとめつつ、うつ病の経過症状のメモも置いておく日々。

じつはRouterboard User Group JPの中の人でもある。

Amazon欲しいものリスト / Arm板を恵んでくれる人募集中

2019-09-14 13:45:50AIX、UNIX、LinuxCPU, CPU frequency management, cpufreq, governor, schedutil