cpufreqの「conservative」governorについての覚え書き - 試験運用中なLinux備忘録・旧記事

cpufreqの導入後、一部アプリケーション*1の使用時を除いて、大部分はCPU使用率に基づいて自動的にクロック周波数や電圧を上げ下げするondemandという動作モード(governor)で動かしてきた。
ところが、そのクロック周波数の変化をリアルタイムで見ている*2と、「負荷が上がるとすぐにクロックも上がり、負荷が下がるとすぐに下がる」のはよいのだが、あまりにも反応が良すぎてクロック変動の頻度が無駄に高くなってしまっていて、あまりハードウェアに優しいとは言えない気もする。
cpufreqには、ondemandと似た動作モードに「conservative」がある*3のだが、これをうまくチューニングすることができれば、頻繁なクロック変動をある程度抑えることは可能。手元の環境では、Compiz Fusionのスケールや各種スイッチャの使用時やキューブのマウスでの回転時など、CPUの使用率が上がるとすぐにクロックが上がってしまっていたが、conservativeにすることで、これらの操作で突然クロックが上がるということはなくなった。*4

cpufreqdのconservative固有な設定項目

cpufreqdでのconservative固有の設定として

down_threshold: 負荷が下がったとき、CPU使用率がこの値を下回るとクロック/電圧を下げるようにする*5
freq_step: CPU使用率の変動によりクロック/電圧を上げたり下げたりするときの変動ペース(最大クロックに対するパーセンテージ形式)で、低ければゆっくり、高ければ急に変動するようになる

の2つ*6がプロファイルの定義の中に記述できる。*7これら2つの値を調整し、試行錯誤しながら最適な値を探し出すことになる。
下はconservativeを使用したプロファイルの定義例。環境や好みなどにより、調整の必要な部分がある。
ファイル名: /etc/cpufreqd.conf

[Profile]
name=conservative min-max
minfreq=1000000
maxfreq=2200000
up_threshold=70
down_threshold=35
freq_step=20
policy=conservative
[/Profile]

注意しなくてはならないのは、使用可能なクロック周波数は必ずしも均等に区切られているわけではないという点。手元のCPU(Athlon64 3500+)では

$ cpufreq-info | grep "available frequency steps"
  available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz

のように最低の周波数とその1段階上とが大きく離れているのが難しいところで、滑らかに変動させようとしてもそうはいかない。freq_stepが1桁だとクロック周波数は非常に上がりにくい*8ため、大きめの値をとるしかない。あるいは、プロファイルの最低クロックをCPUの持つ最低クロックではなく、それより上の値(この例では1.8GHzなど)にする手もあるが、省電力効果は薄まる。
なお、利用可能なクロック周波数をGUIで調べるには、cpufrequtilsに加えてZenityをインストールした状態で、コマンド実行のダイアログに

sh -c 'zenity --info --text "$(cpufreq-info | grep "available frequency steps" | cut -d : -f 2)"'

をコピペして実行してもOK。

conservativeのデメリットとその対処

ondemandで動作しているときには負荷の上がったときにすぐクロックが上がるため、それほど動作が遅めに感じることはなかったのだが、conservativeでは、クロックが上がりにくい分だけ、急な負荷上昇時に遅く感じることが多い。
手元の環境では、Webブラウザの風博士で一気に10以上のURL*9を続けて開いていくという処理を日常的に行っているのだが、最初の幾つかのタブを開くところでは、体感的に明らかに遅くなってしまった。*10その後しばらくは高いクロックで落ち着くのだが、しばらく新しいページを開かないとまた最低クロックに戻るので、次に続けてタブを開くと同様に「遅い」状態が発生する。
この他にも、作業の内容(CPU負荷の変動のしかた)によってはconservativeには不向きなものがある。*11
そういったときに役に立つのがcpufreqdのプログラム名によるプロファイル切り替え機能で、風博士の例では、プロセス名「kazehakase」を「programs」の中に記述したルールを作成し、ondemandのプロファイルと関連付ける。あるいは、頻繁なクロック/電圧変動を防ぐ目的で、最低クロックと最大クロックを(高めの)同じ値に指定したプロファイルを指定してしまう手もある。
下は該当部分の設定例(風博士の動作時はondemand)。
ファイル名: /etc/cpufreqd.conf

[Profile]
name=ondemand min-max
minfreq=1000000
maxfreq=2200000
up_threshold=70
policy=ondemand
[/Profile]

[Rule]
name=ondemand/min-max
cpu_interval=0-100
programs=kazehakase
profile=ondemand min-max
[/Rule]

ただし、動作プログラム名による指定の場合、「そのアプリケーションを限られた時間しか使用しない」ということが前提となってしまう。手元の環境では、風博士は特定の用途で短い時間だけ使用するという使い方をしているためにこのような対処ができたのだが、Firefoxはほとんど動かしっぱなしにしているため、「Firefoxの動作中はondemand」という設定を作る意味はなく(最初からondemandで動かすのとほとんど同じになってしまう)、低クロック動作時に重く感じることは出てしまう*12。
プログラム名指定による自動プロファイル切り替えでも難しい場合、一時的に手動でのプロファイル切り替えを行うのも手かもしれない。
その他、全般的にアプリケーションの起動が遅い(初期化処理時に低クロックで動作するため)気もするが、これはどうしようもない。また、先にも触れたが、CPU負荷の急な上昇時にはクロック上昇の反応が遅い分だけ動作が遅く感じることが出てしまう。こういった部分が許容(我慢)できないのであれば、conservativeを使うのはやめたほうがよいかもしれない。CPUの低クロック時の動作速度によるところも大きい気がするので、体感的にどう感じるかによって、どのようにするのが最も最適(電力に無駄がなく、かつ可能な限り快適な状態)かは変わる。
とにかく、試行錯誤を繰り返して最適な設定を目指すことが重要。

使用したバージョン:

Linux 2.6.26 (tuxonice-sources 2.6.26)
cpufrequtils 002(002-r4)
cpufreqd 2.2.1

*1:低いクロックでも快適に動作するものの、CPU使用率が100%になってしまうものなど

*2:手元の環境ではGKrellM上でgkrellm2-cpufreqプラグインを使用してgovernorとクロック周波数を見ている

*3:ondemandと違うのはクロック/電力がすぐには変動しないことと、ondemandよりもこの変動に関する挙動を細かく制御できるという点

*4:幸い、手元の環境では、これらの動作が(低いクロックのまま行われても)重く感じることはなかったが、これはハードウェア性能によるため、どんな環境でも「低いクロックでもこれらの操作は快適」ということを保証することはできない

*5:逆に、これよりもCPU使用率が高いとクロック/電圧は下げない

*6:詳細な説明は「man cpufreqd.conf」や/usr/src/linux/Documentation/cpu-freq/governors.txtに載っている

*7:これらの値は/sys/devices/system/cpu/cpu[CPU番号]/cpufreq/conservative/以下に格納され、読み書きできる

*8:高負荷時にかなりの時間、「最低クロックのままCPUを100%使用する」という状態が続いて、体感的にかなり遅くなる

*9:重いページが多い

*10:この間のクロックは最低の値のままで、CPU使用率は100%という状態

*11:処理の重いゲームの類は特に厳しそう

*12:Firefoxに関しては、バージョン3系でかなり軽くはなっている