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