ハードウェアベースのトレースでLinuxのタイムイーターを狩る
著者：R. Dienstbeck, F. Berat - Fa.ADIT
発行日
2018年11月27日
会社概要
Advanced Driver Information Technology(ADIT)
所在地
Hildesheim, Germany
会社規模
従業員67名（2021年1月現在）
産業
自動車
ターゲットシステムのランタイム動作の分析
ターゲット・システムのランタイム動作を解析する能力は、デバッグプロセスにおいて非常に重要であるが、見落とされがちです。多くの場合、リアルタイムシステムでは、答えが遅れることは、間違った答えと同じくらい悪いことになります。特に Linux の世界では、組込みシステムの性能を測定するのに役立つ様々なソフトウェアツールが存在しますが、時には問題を複雑にしてしまうこともあります。この記事では、ヒルデスハイムにある Advanced Driver Information Technology GmbH (ADIT)社が、このような問題を克服するために、ローターバッハ 社のTRACE32 （非侵入型ハードウェアベースのトレースツール）をどのように使用したかを紹介します。
次世代コックピットシステムの創造者
ADIT社は そのソリューションの中で、 Arm とIntelプロセッサの両方にLinuxを導入 し、SystemTapを使用してシステム全体のパフォーマンスを測定し、ボトルネックを特定して除去しています。SystemTapは、アップローブとkprobeと呼ばれるLinuxの優れた機能を利用し、それぞれユーザーレベルとカーネルレベルの関数の動的トレースを作成することができます。
製品紹介
- カバーオペレーティングシステム
- ハイパーバイザ技術
- 自動車製品のミドルウェアレベルのコンポーネント
Armデバイスでは 、1回のアップローブコールに2倍の時間がかかっていました。
軽～中程度のシステム負荷では、実際に問題はなく、SystemTapのようなソフトウェアツールがシステム全体のリアルタイム性能に与える影響は小さいと予想されました。予想外だったのは、Arm ベースのプラットフォームでは、インテルベースのプラットフォームよりもシステムの速度が大幅に 低下していたことでした。
この問題を確認するため、ダミーの関数を作成し、アップローブの計測を行いました。その結果、Arm デバイスではアップローブを1回呼び出すのに2倍の時間がかかっていることがわかりました。アップローブは内部的にkprobeを使用しているため、当初はkprobeが原因ではないかと疑われました。kprobeはインテル製プロセッサよりArmプロセッサ の方が実際には速く動作したのでこれは間違いでした。
問題はソフトウェアトレースコードにあったため、ソフトウェアトレースでは問題を特定できませんでした。
TRACE32 ハードウェアベースのトレースツールPowerTrace
ADITは、ハードウェア・トレース機能を備えたTRACE32 PowerTraceの使用を決定しました。ハードウェアベースの トレースはターゲットのタイミングに全く影響を与えず、小さなコード部分でも非常に深い解析が可能になります。Arm 、Intelの両デバイスは 非侵入的なプログラムフロー情報を提供することができます。 Armの場合、これはETM（Embedded Trace Macrocell）と呼び、インテルは同等のものをインテル・プロセッサー・トレース (IPT）と呼んでいます。
コードの実行に関する情報は、一連の専用ピンを介して発せられます。TRACE32 ツールはこれらのピンに接続してこのデータを収集し、それを解析してアプリケーションの機能フローと各機能の詳細なタイミングを生成します。
TRACE32 完全なプログラムフローを記録し分析します。
複雑な環境においても、TRACE32 はユーザーレベルのアプリケーションとカーネルコードを含む完全なプログラムフローを記録し分析することができます。システム全体の機能フローが再構築され、タイミンググラフや関数階層として統計的に表示されます。
カーネルとプロセスを含む完全なLinuxシステムの実行を表示すると、非常に大きなチャートになりますが、TRACE32 は重要な部分の分析を支援します。これにより、ADITのエンジニアは、カーネルのkprobeとuprobeの部分に集中することができました。
TRACE32 完全なプログラムフローを記録し分析します。
リアルタイムトレースがなければ、この問題を見つけることはほとんど不可能だったでしょう。ADITは 、どこを見ればいいかを知ることで主な問題がカーネル・コンフィギュレーションにあることを突き止めた 。別のプラットフォームからカーネルを移行する際、CONFIG_PREEMPT_TRACEの一時的な設定がうっかり有効のままになっていたのです。トレースにより、 Arm ではスタックの巻き戻しが発生したが、インテルでは「no-op」となり、両者の間に大きな性能差が生じたことがわかりました。TRACE32 の高度な解析機能を使うと、2つのボトルネックがあることがすぐに明らかになりました（図1と図2参照）。
最も注目すべき点は、Arm プラットフォームの アップローブ が preempt_disable()と preempt_enable()を4回呼び出し、そのたびにスタックフレームのチェックが行われ、約0.6μ秒かかり、合計で2.4μ秒の遅延が発生したことです。これはインテル・プロセッサでは発生しませんでした。たった2.4μsの差はそれほど大きくないように思えるかもしれないが、毎秒のアップローブへの呼び出しが多いため、すぐにかなりの遅延になります。さらに掘り下げると、2つ目のボトルネックは、アップローブに必要な文字列操作であることが判明しました。このボトルネックは、Arm とインテルとのアーキテクチャの違いに起因するものです。
