起動時に「通常の」動作を示す90秒のConky.gif
を作成しました。
cron
jobs(たとえば、毎日の電子メールバックアップ)は@reboot時に実行され、シングルコアが100%に急上昇します。通常の起動.gif
:
これは同じカーネル4.14.13
の下にありますが、セッション全体で周波数がターボブーストモードのままだった2018年1月13日の異常な動作については説明していません。
今日はカーネル4.14.13で再起動しましたが、昨日は4.14.12のように動作しています。私は違いを説明することはできず、この質問に異議はありません。
これらの結果は両方とも、ラップトップ内蔵1080pディスプレイの非フルスクリーンで10個のタブを開いたFireFoxと、Thunderbolt 3USB-C-HDMIアダプターを介して接続された外部TVで映画をストリーミングするフルスクリーンで1個のタブを開いたFireFoxを使用しています。すべてのテストはSkylakei76700HQで行われました。
4.4
、4.10
、および4.14
(バージョン4.14.13まで)でサンプリングされたすべてのカーネルは、低頻度で高いCPU%を示しました。
Meltdownのセキュリティホールの影響を監視するためにさまざまなカーネルを試しているときに、温度が10度上昇するターボ速度でクロック周波数が常に実行されているという無関係な変化に気づきました。
唯一の違いは、カーネルバージョン4.14.12
(高CPU、低周波数)とカーネルバージョン4.14.13
(低CPU、高周波数)の起動です。
Ubuntu 16.04.3 LTSは両方のテストで使用され、その間にapt-get
の変更はありません。
どちらのテストでも、nVidia GTX 970Mは無効になっており、IntelHD530統合グラフィックスのみが使用されています。 nVidiaがカーネル4.14.4でアクティブ化されたとき、CPU%はそれほど減少していないように見えましたが、デスクトップでのWindowsの移動はInteliGPUほどスムーズではありませんでした。
私の他のラップトップはIvyBridge 3630QM CPUを搭載しており、使用していた3年間で非常に異なる動作を示します。 CPU%は、プロセッサが弱いためわずかに高くなりましたが、周波数は常に低と高の間でバウンスし、ほとんどの時間が中間で費やされていました。周波数の振る舞いははるかに好ましいと思いますが、それは主観的です。誰かが興味を持っている場合は、後で3630QMCPU用にConky.gifを作成します。
低CPUと高周波数、または高CPUと低周波数のどちらが良いですか?
この17インチのラップトップは5.5インチの1080pスマートフォンほど簡単にコートのポケットに収まらないため、外に出ないため、バッテリーの使用はそれほど問題にはなりません。低CPU%または低周波数がバッテリー寿命に優れているかどうかを知ることはまだ良いでしょう?
この質問への答えは実際にはユースケースによって異なりますが、Haswellの投稿を覚えておいてください。コアの速度はコアごとのニーズに基づいて上昇する可能性があり、「アンコア」または非CPUバウンド(例としてメモリバウンド)は上昇する可能性があります。コアのパワーバジェットに影響を与えない周波数。
一般に、ランプアップの待ち時間がインタラクティブな感覚に影響を与えない場合は、周波数をできるだけ低くする必要があります。
CPUのターボ速度は、パッケージの電力と熱のバジェットによって制限されます。ほとんどのコアが低周波数で実行されている場合、単一のスレッドがより長く、より速くターボすることができます。
また、AVX2などの一部の関数は整数演算よりも大幅に多くの電力を必要とし、ほとんどのチップでは、すべてのコアが高速の場合、CPU周波数が基本周波数より低くなることに注意してください。
私はあなたが使用しているツールに精通していませんが、この変更のために、コア周波数ではなくTSC周波数を調べている人がいるため、これが観察されない場合があります。
残念ながら、ターボブーストの動的な性質と、コアおよびパッケージの温度に関連するいくつかの目に見えないPID関数のために、%used数はあまり役に立ちません。
許容可能なレイテンシー(Linuxのスケーリングドライバーの最新のイテレーションでははるかに優れています)と最低温度をターゲットにすると、シングルスレッドのパフォーマンスが向上する可能性があります。
確認します
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
そして:
/sys/devices/system/cpu/*/cpufreq/scaling_governor
performanceガバナーを使用していないことを確認すると、レイテンシーのために個々のスレッドのパフォーマンスが犠牲になります。