web-dev-qa-db-ja.com

intel_pstateドライバーを使用したバッテリーの恐ろしいパフォーマンス

編集：Ubuntu（mate）20.04、intel_pstateドライバー。コンピューターは、Intel Core i7 i7-8565Uを搭載したRazerブレードステルスウルトラブック（2019年初頭）を使用しています。

TLPをACモードに設定している場合でも、バッテリー電源のみで奇妙な動作（極端なスローダウン）が発生します。 cpufrequtilsをパフォーマンスモードに設定すると（特に、マルチスレッドの場合）、問題はさらに悪化します。

シングルスレッドの場合（つまり、メインスレッドのみ）から始めます。ファイルまたはWebカメラからのビデオフレームでOPENCVフィルターのカスケード（ガウスぼかしなど）を実行しています。最初にすべてのフレームをメモリにロードしても問題ありません（つまり、ディスクやデバイスのI/Oの問題ではありません）。以下は、単一ループ（1フレーム）の処理時間です。これは複雑なコードではありません。基本的に、それはやっています：

Filter filters[400]
while( cap.read(frame) )
{
 for( int i=0; i<400; ++i )
 {
  filters[i].dofilter(frame);
 }
}

ここで、filters [i] .dofilterは、たとえばcv :: GaussianBlur、resize（）など、宛先cv :: Matが事前に割り当てられています（追加の割り当ては行っていません）

これはCPUのみを使用しています（つまり、OPENCV透過openCLなどを使用していません）。

シングルスレッド

AC  + powersave:    71 msec (variance 70.5-71.5)
AC  + performance:  67 msec (variance 66.5-67.5)
BAT + powersave:    95 msec (variance 84.0-115.0)  *1
BAT + performance:  104 msec (variance 76.0-202.0) *2

1* Note: spikes to 110+ about every 5 sec
2* Note:  most ~96, with few spikes low to 80s and high to 120s

方法：各条件を60秒間10回実行（10回の実行ごとに約600フレーム= 6000）、ランダムに順序付け（熱、バッテリー電圧などが交絡しないようにする）。

すべてのループで同じ入力フレームを使用しています（つまり、毎回処理しているのが異なる画像コンテンツのためではありません）。文字通り、タイムステップごとにまったく同じ入力を処理しています。 ACアダプターのプラグを抜いたり差し込んだり、cpufrequtilsを使用して省電力/パフォーマンスを設定したりすると、フレームごとの処理時間が変化するのがすぐにわかります。

私は完全に途方に暮れています。

私は、Intel Core i7 i7-8565Uを搭載したRazerブレードステルスウルトラブックを使用しています。 Ubuntu（mate）20.04、intel_pstateドライバー。

だから、私は3つの特定の質問があります：

1）一体何が起こっているのですか？

2）TLP（kernel params？）を設定して、ACのように動作するように強制する方法（ACの場合と同じくらい高速に、CPU /メモリにバインドされたシングルコアプログラムを実行するのに十分なバッテリーが提供できることを確認してください）？そんなに多くはしていません！

3）バッテリー電源で発生する秘密/奇妙な設定はありますか？特にマルチスレッドに関連していますか？問題は非常に並列化可能です-基本的に、並列に実行できる8つの独立したフィルターチェーンがあります。通常私はこれを行います。 ACでこれを行うと、次のようになります。

MULTITHREAD（8スレッド）

AC  + powersave:    28.6 msec (variance 26.8-31.1)
AC  + performance:  28.8 msec (variance 26.6-31.2)
BAT + powersave:    39 msec (variance 36.0-64.0)   *3
BAT + performance:  176 msec (variance 39.0-202.0) *4

3* Note: this is very tame compared to if I run with webcam -- then it spikes heavily between 40 and 90

4* Note: will update at 40 msec for a few frames, then go to 180 msec for a long time, then burst at 40 for a few.

ソフトウェアは、スレッドプールを介してマルチスレッド化されています。私はロックをチェックしましたが、極端なマルチスレッドの場合でもロックを待機するのに時間は費やされていません（これは、もともと問題だったと思っていたため、実際に最も時間を費やした場所です...） 2〜8スレッドでも同様の結果が得られます。より多くのスレッド（特にパフォーマンスモード）を使用すると、バッテリーの速度が遅くなり、ACを使用するとスレッドの数が多くなります。

編集：TLPを無効にしても問題が発生します。私はまだ古いacpi周波数ガバナーへの切り替えを試していません（うまくいくと思いますか？）

編集2：シングルスレッドモードの場合、htopはペグされた単一のCPUコアのみを表示します（つまり、openmpなどを使用して、より多くのコアをベクトル化して使用していません）。

linuxpower-managementacpicpu-frequencybattery
2
rveale

問題はintel_pstateドライバーでした。

ブートカーネルパラメーターを介して元のACPIドライバーに切り替えました。具体的には、/ etc/default/grubで、DEFAULTブート行を次のように変更しました。

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_pstate=disable acpi=force"

（update-grub後）。

さて、まったく変更がない場合でも（つまり、デフォルトの「オンデマンド」）：

MULTITHREAD（8スレッド）

BAT + ondemand:     38.5 (37.5 ~ 40.0)
BAT + performance:  31.8 (30.1 ~ 35.0) *1

1 *数秒ごとに35の非常に小さなスパイクが見られますが、それは理にかなっています...

皮肉なことに、通常のワークロード（ブラウジング、EMACS、Wi-Fiなど）中の電力消費も、実際にはintel_pstate（平均590 mA対660 mA）よりACPIドライバーを使用した方が優れています。幸せな（しかし気になる）副作用。

編集：1つの欠点は、intel_pstateドライバーを使用しない場合、サスペンド（スリープモード）がより多くの電力を消費するように見えることです。 12時間ごとに約10％...

3
rveale

これが私のカーネルmake "DESCEND only" -benchmarksです（つまり、何もする必要がない場合はmakeだけです-数秒）。

Makeの-jオプションに気付くまでに少し時間がかかりました。ターボブーストとSMT /ハイパースレッドの設定を変更するために再起動する必要はありません。これらには/sysからアクセスできます。

私のTDPは28Wです。これはラップトップではなく、i5-8259Uでもあります。それは通常（今のように）3.5W-5Wを消費します。これは、私が物理的に測定したワットに焦点を当てて、私が指摘した結果の一部です。

time make -j10 -O O=../make-out/

TB+HT,mitigations=off

-j8:    4.8s    57W (max.)
-j4:   12.3s    20W (-35W)  
no-j:  21.7s    19W (max.)
-j4II:  6.4s    45W

代わりに、ジュールではより正確になります。 57Wにはファンが付いていると思います。 2つの-j4結果は、次のことを示しています。総エネルギー（Ws =ジュール）はほぼ一定です。

TB no, HT yes
-j10:  7.7s  22W

そして私が書き留めた最後のテスト：

TB 25-35-1sec "tau", HT yes, mitig.=off
-j10:  5.2s  40W

このターボブースト設定はBIOSからのものです-「最大57W」を制限するのに役立つようです。最初の実行から。

しかし、sysfsのintel_pstate/max_perf_pctに75（パーセント）が書き込まれたため、ブーストを行うためのより良い方法が見つかりましたが、3.8GHzではなく3.0GHzにしかなりませんでした。

今では、35W（最大44W）の5.5秒で、50W程度の4.8秒と比べて、それが得られます。ブーストなしは25Wで6.7秒です。

よりアクティブなコアとより高いCPU周波数は、巨大な時間差およびワットを生じさせる可能性があります。 GPUはさらに（例では）、ファンを追加することもできます。

バッテリーがすぐに空になるだけでなく、アンペアが多すぎるという問題がある場合は、今はしません。しかし、私の測定では、差が非常に大きくなる可能性があり、一部のスロットルが作動する可能性があることを示しています-通常は温度です。

しかしカミソリの刃のウルトラブック-バッテリーが弱い！

0
rastafile