2 ＜動作の見える化＞マルチコアの問題解決に役立つ可視化の技術

2.1.2.1 並列実行の可視化

並列実行に課題がある例を紹介し、可視化を行う理由について説明する。

図 2 は、並列実行があまりうまくいっていない例

• 各プロセッサに空き時間がある。
• 同時に終わっていない。

可視化により、ひと目で問題の有無や深刻度、状況が分かる。さらなる原因解析についても、可視化した結果（グラフや図）を参照しながら進めることができる。

2.1.2.2 OSオブジェクト状態の可視化

組込みシステムではOS（リアルタイムOS）を使うことが多い。リアルタイムOSにはOSオブジェクトの状態をログとして記録する機能があるが、ログだけから現象を把握することは容易ではないため，可視化が重要である。

ログでは、各コアのイベントが1次元で並んでいるため、コア間の関係が読み取りづらい。

2.2.1.1 負荷分散の可視化に関連する用語

負荷分散の可視化に関連する用語を説明する。

• 処理単位
  • 前ページでは単に「処理」と記載したが、処理の単位としてはさまざまな可能性がある。典型例は「スレッド」、「タスク」、「プロセス」など。
• CPU利用率（アイドル時間）
  • 各プロセッサコアで有効な処理を実行している割合を「CPU利用率」と呼ぶ。アイドル状態になっている時間が「アイドル時間」である。
  • マルチコアの場合、他プロセッサが利用している資源を待ってビジーウェイトしている時間など、実行しているが有効とは言えない処理時間もあるため、注意が必要である。
• アプリケーションの逐次実行部分
  • ある処理を実行している時、同時に実行できる処理が他に存在しない時間帯を「逐次実行部分」と呼ぶ。アムダールの法則をもとに理論並列性能向上率を考える上で、逐次実行部分の割合は重要である。

2.2.2.1 制御依存，データ依存

依存関係には「制御依存」と「データ依存」がある。

制御依存：プログラム制御上の順序関係

例:

if 処理A then 処理B else 処理C

データ依存：データ（変数など）の読み書き順序によって規定される順序関係

例:

i = f(x);   // 処理A
j = g(i);   // 処理B

としたとき、処理Bは処理Aの結果データを使っているのでデータ依存。

2.2.3.1 メモリ読み書き順序の可視化の例

逐次実行および並列実行に対し、トレースなどを用いた動的解析によりメモリアクセス履歴を取り、対応する命令アドレス（プログラム上の場所）、メモリアドレス（プログラム内の共有変数名）、アクセス属性（Read/Write、Lockなど）、値、時刻などを表示する。

同一メモリアドレスに対し、逐次実行におけるメモリアクセス順と異なる箇所、あるいは同時実行可能性がある箇所の色分け表示などを行って可視化する。

図 8 は右図はIntel社 Inspectorにおける可視化の例。

保護されていないデータ競合（同時アクセスの可能性）箇所、および該当共有変数をソースコード上で色分け表示している。

2.2.3.2 RAW/WAW/WAR

メモリ読み書き順序が問題となる場合には、RAW（Read After Write）、WAW（Write After Write）、WAR（Write After Read）の3種類がある。Read After Readは順序が変わっても不具合が起こらないため、考慮しない。

図 9 、 図 10 、 図 11 は、逐次実行ではスレッド１→スレッド２の順だったものが、同時実行により、メモリアクセス順が入れ替わる例である。すべてのRead、Writeは同じメモリアドレスへのアクセスとする。

2.2.3.3 動的解析を使う理由

メモリ読み書き順序を解析するためには、プログラム上のメモリアクセス箇所と、その時のメモリアドレスを特定する必要がある。解析には「静的解析」と「動的解析」があるが、以下の理由で可視化には動的解析が使われることが多い。

大域変数宣言された共有変数などは静的解析で特定可能であり、コンパイラなどで自動的に対応できる。

Ｃ言語のポインタ変数などは、多くの場合、実際に実行させなければ同一アドレスになるかどうかは分からず、動的解析が必要。すべてのポインタ変数への読み書きを保護する、あるいは順序制約をつけると性能が大幅に落ちるため、必要な箇所のみの保護にしたい。

例えば、次の関数

void func1(int \*a, int \*b) { ... }

において変数aとbが同一アドレスになるかどうかは、呼び出し側に依存している。開発プロジェクト内の関数利用規則で制約をかけたとしても、人的ミスにより誤った使い方をすると不具合が生じる。このような不具合の発見には、動的解析による可視化が有効である。

2.2.4.1 タスクとは

可視化では、リアルタイムOSの考慮が必要になる。

• タスク
  • リアルタイムOS上の処理単位であり、状態を持つ。
• タスクの基本的な状態（ 図 12 参照）
  • 実行状態
    • プロセッサで実行されている状態
  • 実行可能状態
    • 実行すべき処理があるが、他に優先すべき処理があり、実行が保留されている状態
  • 待ち状態
    • 事象の通知を待っている状態
  • 休止状態
    • 起動していない状態

2.2.4.2 シングルコア実行のタスクスケジューリング

タスク状態を可視化することにより，処理が滞りなく進んでいるかどうかを判断できる。

• シングルコア実行におけるスケジューリング
  • プリエンプティブな優先度ベーススケジューリング。
  • 優先度の高いタスクが存在すれば、低いタスクは実行されない。
• 可視化（下図）において着目する点
  • どのタスクによりプリエンプトされ、処理が止まっているか
  • 何が原因で待ち状態となり、処理が止まっているか

2.2.4.3 マルチコア実行のタスクスケジューリング

マルチコア実行におけるタスクスケジューリングの基本は、以下の二つ。

• AMPスケジューリング（ 図 14 ）
  • タスクは設計時、（静的に）設計者によって特定のコアに割り付けられる。
  • コア内はプリエンプティブな優先度ベーススケジューリング。

• SMPスケジューリング（ 図 15 ）
  • タスクは実行時、（動的に）OSにより実行するコアが決定される。

2.2.5.1 同期通信オブジェクト

リアルタイムOSには、数種類の同期通信オブジェクトがある。マルチコア実行で処理が理想的に動作している場合、これらのオブジェクトの状態を可視化することにより原因を解析が容易となる。

• FIFO
  • 通信のためのオブジェクト。
  • 内部にバッファを持ち、送受信が可能。バッファがフルの場合に送信すると、待ち状態になる。
  • バッファがエンプティの場合に受信すると、データが来るまで待ち状態となる。
• セマフォ
  • コア間のタスクの排他制御のためのオブジェクト。
  • 共有資源を操作する前に取得し、操作後に返却する。
  • 資源数をカウントするカウンタを持つ。
  • 取得時に資源数が0なら待ち状態となり、他のタスクが資源を返却すると待ち状態が解放される。
• スピンロック
  • コア間の割込みハンドラ間、および割込みハンドラ-タスク間の排他制御を実現するためのオブジェクト。
  • セマフォと異なり，資源数が0の場合は実行状態のまま資源の解放を待つ。
  • 取得した際には割込みも禁止するのが一般的。
  • 取得を試みている間も、割込みを禁止する場合がある（複数のスピンロックを取得する場合）。

2.2.5.2 FIFO

FIFOによるデータ通信で知りたい情報（ 図 18 の可視化例を参照）

• タスクがどの程度待っているのか、どの程度の頻度で送受信しているのか
  • タスクの状態を可視化
• バッファサイズは十分なのか
  • バッファの状態を可視化

2.2.5.3 セマフォ

セマフォによる排他制御で知りたい情報（ 図 19 の可視化例を参照）

• タスクがどれだけ待っているのか、誰に待たされているのか
  • タスクの状態を可視化
• 優先度逆転やデッドロックは起きていないか
  • タスクとセマフォの状態の可視化

2.2.5.4 スピンロック

スピンロックによる排他制御で知りたい情報（ 図 20 の可視化例を参照）

• タスクがどれだけ待っているのか、誰に待たされているのか
  • タスクの状態を可視化
• 優先度逆転やデッドロックは起きていないか
  • タスクとスピンロックの状態の可視化
• スタベーション（飢餓）が発生していないか
  • 各コアのタスクやISR（interrupt service routine）の状態を可視化

2.2.6.1 割り込み応答時間の可視化

割込み応答時間の悪化の原因を特定するために、可視化が有効。

• 割込み応答時間の最悪値に着目
  • 物理的な割込みが入ってから割込みハンドラが起動されるまでの時間
• 割込み応答時間が悪化する要因は割込み禁止にある
  • シングルコアの場合
    • 最悪値はコード中の最長の割込み禁止区間の長さと一致する。

2.2.6.2 スピンロックの解析

マルチコア実行で発生する状況を解析するために、可視化が有効。

• スピンロックの取得と共に割込みを禁止するため，スピンロックを取得している区間は割込み処理が遅延する。
• 2段以上のスピンロックの取得の場合、割込みを禁止して取得を試みるため，他のコアのタスクの振る舞いにより、割込み禁止区間が変化する。