intel_pstateドライバを使用したバッテリー性能が悪い

エディタ：Ubuntu（mate）20.04、intel_pstateドライバ。私のコンピュータは、Intel Core i7 i7-8565Uを搭載したRazer Blade Stealth Ultrabook（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);
 }
}

ここで、フィルタ[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 Blade Stealthウルトラブックを使用しています。 Ubuntu（mate）20.04、intel_pstateドライバ。

だから、3つの具体的な質問があります。

1）正確に何が起こりましたか？

2）TLP（カーネルパラメータ？）をACにあるかのように強制的に設定するにはどうすればよいですか？ ）？そしてそれはまだ終わっていません！

3）バッテリー電源に秘密/異常な設定がありますか？特にマルチスレッドに関連していますか？問題は並列性が非常に高いことです。デフォルトでは、並列に実行できる8つの独立したフィルタチェーンがあります。通常私はそうします。 ACでこれを行うと、次のことが起こります。

マルチスレッド（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や他のものを使用しません）。