125.ACPI.sysの問題解決方法
今回は少し技術的な話しとなります。昨年会社で購入したWindows11のPCでAPCI.sysの負荷が極端に上昇する問題が購入当初から発生していました。この問題の回避方法を見つけたので共有しておきます。
ハイブリッドCPU
その前に今回問題の発生したPCについて書いておきます。ちなみにモデルは以下の記事で紹介しています。
今利用しているノートPCのCPUが「13th Gen Intel(R) Core(TM) i9-13980HX」なので、ノートPC用のCPUとしては最高クラスの能力があるCPUです。とはいえ１年前の話ですが・・・CPUの移り変わりは激しいですね💦このCPUは、ハイブリッドCPUで
P-Core：Performanceコア
E-Core：Efficientコア
と、作業負荷によって使い分けを行っています。スマートフォンに利用されているCPUも「big.LITTLE」と言って、使い分けを行う仕組みになっています。AMDのRyzenの場合は、従来と同様全てのコアが同一の能力を持つ形となりますが、今後はハイブリッドCPUが主流になっていくと思われます。
何故なら、高効率なCPUコアは最先端プロセスで作り、それ以外のコアは枯れたプロセスで作ることでコスト面での優位性を作り出せるためです。半導体はプロセスが微細化されると、製造の歩留まりが悪化するためコストが悪くなります。チップ間の高速通信（チップレット）技術が成熟してきたのも理由の一つです。
今回は初めて利用するハイブリッドCPUなので期待していたのですが、実際利用してみると想定より遅く感じました・・・そこで、その原因を探ってみることにしました。
遅延がひどい
このCPUの特性を確かめるため、開発をしている半導体搬送シミュレーターを実際に動かし能力測定グラフを確認すると、アベレージこそは確かに早いのですが、時折大きな遅延が発生しています。
以下は、その時のグラフです。左の単位はus（マイクロ秒）
このグラフはCPUを8コア利用し、1コアあたり375の機器を制御しています。1制御サイクルが何usで終わっているのかを表しています。
Max値がかなり高い頻度で上に振れており、時折 10000us以上に振れる時もありましたので、安定している状況とは言えません。
原因
大きく4つの問題を見つけました。
１．CoreParking
利用していないCPUコアを極力消費電力を抑えるParking状態にして、必要に応じて動かす機能です。CPUコアに作業が割り当たったときに即座に動けないので、これが大きな遅延が発生する原因です。
以下は先ほどのグラフと同じ条件でCoreParkingを無効にした時のグラフです。
このグラフから、CoreParkingの影響が分かると思います。
一般的に能力の高いCPUを利用する場面では、バッテリー駆動で動かすことは殆どありませんので、安定性を求めるのであればCoreParkingを「無効」で利用した方が良いと感じます。
有効・無効は以下のコマンドを管理者権限のコマンドプロンプトで設定します。
無効
powercfg /setacvalueindex SCHEME_CURRENT SUB_PROCESSOR CPMINCORES 100
50%有効
powercfg /setacvalueindex SCHEME_CURRENT SUB_PROCESSOR CPMINCORES 50
有効
powercfg /setacvalueindex SCHEME_CURRENT SUB_PROCESSOR CPMINCORES 0
上記3つのコマンドの何れかの後に、以下のコマンドで設定される
powercfg /setactive SCHEME_CURRENTこの設定は、電源管理設定と紐づいており再起動しても設定は維持されます。
尚、設定の効き具合を確認する場合は、リソースモニターのCPUタブで確認が可能です。（保留と書かれているCPUがParking状態です）
なお、タスクマネージャーのパフォーマンス表示でも表示されるのですが、保留状態にもかかわらずグラフが上振れしている状況で正しく表示されているように見えません・・・ハイブリッドCPUへのOSやドライバ対応が成熟していない印象を受けました。
２．E-Coreを利用してしまう
高い処理能力が必要なアプリケーションを動かす場合に、E-Coreを利用してしまう場合があります。本来は全てP-Coreで動かしたい所です。解決方法としては、AffinityMaskでP-Coreを利用しないようにタスクマネージャーで設定する方法があります。しかし、アプリを起動する度に設定しなければならないので、本来はアプリの設定として実装されているのが望ましいです。
今回問題を確認したので、シミュレーターにP-Coreのみで動作できるようにする設定を設けました。
３．強制スリープする
システムの安定性をチェックする時にOCCTというツールを利用するのですが、以下の設定で動作させた場合に必ずPCがスリープに移行します。（電源管理でのスリープは全て無効）
冷却が追い付かずスリープ状態に移行するようです。試しに同じCPUを利用している他のPCでも同様の現象が発生しましたので、特定のマシンに依存した問題ではない気がしました。
試しにプログラムでループ処理を作り、特定のCPU負荷を100%にしてもスリープに移行したのでハイブリッドCPUに対してのBIOS（Firmware）やドライバの調整不足が伺えました。
この問題の回避方法はP-Coreの最大周波数に縛りを設ける方法です。以下の場所のレジストリ値を変更することで、電源設定に最大周波数の設定が追加されます。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings
\54533251-82be-4824-96c1-47b60b740d00 <--- プロセッサ電源管理GUID
\75b0ae3f-bce0-45a7-8c89-c9611c25e101 <--- 最大プロセッサ周波数GUID
\Attributes 1 -> 2に変更Attributesを１から２に変更することで以下の設定が追加されます。
ここで最大周波数を設定することで、高負荷時の強制スリープを回避することができます。
４．長時間動かすとACPI.sysでDPC Countが増加する
これが最も致命的な問題で、同様の問題に悩まされている方が多くおられることを知りましたが、殆どの問題は音が途切れる現象でこの場合、グラフィックドライバやネットワークドライバを最新のものにし、ネットワークドライバの省電力系設定を無効、さらに電源管理を「高パフォーマンス」にすることで回避できます。
今回このPCで発生している問題は、利用しているPC限定の問題かもしれませんが、ハードウェア割り込み(ISR)が大量発生し、その影響でCPUコアが常に100%に張り付く現象です。
ACPI.sysというのは、マザーボードと電源管理に関連しているWindowsのドライバで、マザーボードのBIOSに問題がある場合には、おかしな挙動になることがあります。
DPC Countというのは、ハードウェア割り込み（ISR）によって、遅延実行される処理の数を指すのですが、PCを放置している状況でもしばらくたつと、DPC Countが一気に増加する現象が発生します。
以下はこの問題を調査するために利用した、LatencyMonというアプリのモニタリング状況です。
この状況になると、一つのCPUコア利用率が100%に張り付きます。注目するところは
DPC Count（回数を確認）
Highest execution（時間を確認）
音が途切れる問題は「Highest execution」の時間が大きくなります。しかし今回の場合「DPC count」が極端な回数となり、一般的にみられる遅延とは現象が異なります。
もちろん、再起動すれば元に戻るのですが、しばらく利用しているとまたこの状況に陥ります。ドライバやBIOSを最新にアップデートしてもこの状況は改善しません。結局の所BIOSやACPI.sysそのものが改善されなければ、ダメかとあきらめていました。
メーカー（ASUS）に問い合わせる
ACPI.sysの問題が致命的なので、この問題についてメーカーに問い合わせを行うことにしました。より詳細な情報を提供するため、WindowsADKのWindows Performance Recorder/Analyzer（WPR/WPA）で情報の取得と確認を行い、その情報も送りました。
実際に送った資料は以下です。
以下はASUSからの返答内容、原文ママ。
平素は大変お世話になっております。
ASUSサポートセンターでございます。
連絡が遅くなり申し訳ありません。
本件について、担当部署と確認したところ、
同じモデルの本体でを3日間ストレステストした結果、 ACPI.sysのISR/DPCカウントはまだお客様の値より低いままです。 外部デバイスが接続されている場合、値が速く増加することが確認されました。
もし、外部デバイスを削減しても問題が解決しない場合、 まずOSを出荷状への初期化をお勧めします。初期化が効果がない場合、 修理依頼して、修理センターにてSSDやマザーボード、他のハードウェア部品をチェックさせていただきます。 （ACPI.sysは電源管理を管理しており、どんなデバイスにも関連があるためです）。
そこで、ノートPCに外部デバイスを一切接続しない状況で利用もしてみたのですが、若干発生しずらくはなったものの、１日に２回程この現象が発生します。
私の経験では、ハードウェアの問題であればもっと頻繁に発生すると感じたので、何かのドライバもしくは、アプリが問題を起こしていると想定しテストを行うことにしました。
解決方法
テストに時間がかかるので、少しづつ記録を取りながらドライバやアプリの無効を試していったのですが、あるドライバを無効にした時にこの現象が全く発生しなくなりました。
問題となっているのはThunderbolt Controllerです。このドライバを無効にしたとしてもUSB等の互換プロトコルで殆どのデバイスは機能するので、問題が発生することは少なく、Thunderboltに特化したデバイスの場合にだけ影響があります。
このようなことから、現在ではこのドライバだけ無効にして利用しています。
電源管理について
今回の調査にあたり、電源管理についても様々な設定を確認したので情報共有しておきます。
ノートPCの場合、通常であれば「バランス」と「省電力」しか選択できないのですが、Quick CPUというツールを利用すると、「高パフォーマンス」やノートPCでは通常利用出来ない「究極のパフォーマンス」を選択可能になります。
以下は設定手順です。
但し、注意点があります。「究極のパフォーマンス」は1つのスレッドへ能力を振りすぎてしまうため、マルチスレッドで動作させた場合に、全体としては安定しない状況となりましたので、おすすめできません。
そのようなことから、安定したパフォーマンスを出す場合は「高パフォーマンス」がベストと言えます。この設定の場合CoreParkingを無効にしなくても遅延が発生しなくなりましたのでおすすめです。
但し、AMDのRyzenの場合は「バランス」でないと本来の能力が発揮されません。これは、PBO(Precision Boost OverDrive)が「バランス」に最適化されているためです。
まとめ
今までのCPUから考えると、ハイブリッドCPUは癖があるように感じます。
ACPI.sysの問題が無かったとしても、わざわざ利用者が設定をカスタマイズしなければ能力が出せないというのは気になるところです。まぁ、そんな使い方するなら「デスクトップにしろ！」って言われそうですが（笑）
デスクトップ版の場合は、E-CoreをBIOSで無効などにもできるので、柔軟性があります。しかし、E-Coreを無効で運用するならそもそも必要無いってことになるので、E-Coreありきで期待したパフォーマンスを出してほしい所です。
普段ソフトウェアのテストにはAMDのThreadripperを利用しています。仮想マシンを２０個程動かして長期間のテストに利用していますが、連続で３０日以上稼働しっぱなしでも問題が発生していませんし、全てのCPUコアが期待通りの動作をしてくれるので、開発しているシミュレーションソフトウェアの調整に大いに役立っています。
ゲームをする場合は、RyzenのX3Dが付いたCPUがおすすめです。キャッシュ容量のおかげでパフォーマンス（高FPS）を維持しやすいです。
今回は偶然Thunderbolt Controllerドライバを無効にすることで問題を回避できたのが幸運でした。
メーカーへの問い合わせや、Web上にも改善方法が見つからなかった（見つけられなかった？）ので、同様の現象でお困りの方は是非試してみてください。
いいなと思ったら応援しよう！
