Autowareにおけるリソース競合の定量化

3.3K Views

March 22, 23

スライド概要

2023/3/13「TIER IV Computing System Workshop 2023」
発表者:石川貴大

profile-image

TIER IV(ティアフォー)は、「自動運転の民主化」をビジョンとし、Autowareを活用したソフトウェアプラットフォームと統合開発環境を提供しています。 #Autoware #opensource #AutonomousDriving #deeptech

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

TIER IV Autowareにおける リソース競合の定量化 2023 / 03 / 13 TIER Ⅳ | Takahiro Ishikawa @sykwer 1

2.

TIER IV プロフィール 石川貴大 (Takahiro Ishikawa) Twitter, Github @sykwer 2020.06〜 TIER IV 在籍 2022.03 東京大学情報理工コンピュータ科学 修了 (加藤研) 2023.04 同専攻 社会人博士 入学予定 専門 オペレーティングシステム, リアルタイムシステム TIER IV での担当 アプリケーションのパフォーマンス, リアルタイム性 ミドルウェア, Linux Kernel, Hypervisor, OS開発 2

3.

TIER IV 01 / 背景と概要 Autowareにおける リソース競合の定量化 TIER Ⅳ | Takahiro Ishikawa 02 / 参考研究の手法 03 / Autowareへの適用 04 / まとめ @sykwer 3

4.

TIER IV Autowareはリアルタイムタスク Autoware (我らが自動運転アプリケーション) には入力〜出力の時間制約がある 4

5.

TIER IV リアルタイムってなに? ● リアルタイムの意味は濫用されがち ○ RTOS: タスクの立ち上がり時間, Context Switchのオーバーヘッドが非常に小さい ● ○ スケジューリング理論 ○ 機能安全保証 うんうん それもリアルタイ ムだね。。。 リアルタイムシステム = 出力の正しさに論理的な正 しさだけではなく, 時間的な制約が加わるシステム = リアルタイム制約のあるシステム ● 予測可能性 = システムが時間制約を守る能力を向 上させる要素 5

6.

TIER IV リアルタイムスケジューリングの前提 前提1: Taskの立ち上がり やContext Switchの遅延 はゼロ 前提2: 最悪実行時間を見 積もることができる Deadline Relative Deadline Slack Current Period 6

7.

TIER IV AutowareでWCET保証は不可能 ● プラットフォーム要因: マイクロアーキテクチャにおけるオペレーションに最悪実行時 間を定義できない ● アプリケーション要因: 外部環境由来によって処理の増減が激しい, キャッシュやメ モリ帯域といったリソースの競合が激しい (Memory Intensive) 7

8.

TIER IV スループット指向システムの予測可能性 ● Autoware は ROS (Robot Operating System) のノードが200以上立ち上がる (スレッド数にして1000以上) ● ノード同士は相互依存関係を持って, Publish/Subscribe 通信を行う ● OS には当面 Linux を採用 → 研究の方向性 (の内の一つ): スループット指向のシステムにて予測可能性をマシに していく 8

9.

TIER IV メモリ資源競合の定量化 ● 本発表の取組: リソース競合の中でも, キャッシュやメモリ帯域といったメモリ資源の 競合について定量化してみる ● 仮説: タスク固有の「リソース競合への感応性」と「システムのリソースに与える負 荷」を定量化 → リアルタイムにリソース競合由来の遅延を算出可能 ● 先行研究: クラウド環境上でのアプリケーション同士のメモリ競合を同様の考え方で 定量化した論文 (MICRO ‘11) ● 先行研究の手法をAutowareに応用してみる 9

10.

TIER IV 01 / 背景と概要 Autowareにおける リソース競合の定量化 TIER Ⅳ | Takahiro Ishikawa 02 / 参考研究の手法 03 / Autowareへの適用 04 / まとめ @sykwer 10

11.

TIER IV 参考研究の概要 Bubble-Up: increasing utilization in modern warehouse scale computers via sensible co-locations (MICRO ‘11) ● 目的: クラウド上の同じホストになるべく多くのアプリケーションを同居させ, クラウド リソースの利用効率を上げたい ● 手段: Applicationそれぞれに対して「固有のsensitivity (システム負荷からの影響 の受けやすさ)」と「contentiousness (システムへの負荷)」 を算出 ● リソース競合によるパフォーマンスの低下を予測 → 根拠をもってアプリケーション を同一ホストに同居させることが可能に 11

12.

TIER IV 参考研究の手法概要 それぞれのアプリケーション固有の「sensitivity (システム負荷からの影響の受けやす さ)」と「contentiousness (システムへの負荷)」を算出 12

13.

TIER IV 参考研究の手法 (手順1) 定められたアドレス範囲に, ランダムアク セス/逐次アクセスをすることで負荷とす る 13

14.

TIER IV 参考研究の手法 (手順2) 1段階目 “Reporter” と呼ばれるアプリケーションの “sensitivity curve” を作成 2段階目 対象アプリケーションと同居したときの “Reporter” のパフォーマンス低下を計測 逆引き (Performance低下度 → Appの相当するメモリ負荷度 ) ReporterのSensitivity Curve 14

15.

TIER IV 参考研究における手法まとめ App1 Reporter Reporter Bubble Bubble App2 Sensitivity Curve の算出 App2 App1 App2 Contentiousness の算出 App2 15

16.

TIER IV 参考研究における評価 ● bigtable, search, youtube などのアプリケーションに対して Sensitivity Curveを作 成 / Contentiousness算出 → それぞれのアプリケーションの特色が判明 ● それぞれのアプリケーションに様々な負荷 (行列計算, 二分木探索, 様々なパター ンのメモリアクセス) を与えて, パフォーマンス低下を予測 → 誤差約2%以下で予測 に成功 ● 許容されるパフォーマンス低下の度合いを制約として, クラウド上リソースの Utilization を上げることに成功 16

17.

TIER IV 01 / 背景と概要 Autowareにおける リソース競合の定量化 TIER Ⅳ | Takahiro Ishikawa 02 / 参考研究の手法 03 / Autowareへの適用 04 / まとめ @sykwer 17

18.

TIER IV Autowareへの適用 概要 ● 参考研究と本発表内容のギャップ: Application単位ではなく, Autoware のプロセ ス同士の競合を扱う点 ● 今回は SensingモジュールのLiDAR点群前処理に注目 18

19.

TIER IV AutowareのSensingモジュール (点群処理) ロボットタクシーのLiDAR点群前処理 19

20.

TIER IV AutowareのSensingモジュール (点群処理) velodyne_convert_node: LiDARパケットをxyz空間の3次元点群に変換 20

21.

TIER IV AutowareのSensingモジュール (点群処理) crop_box_filter_self: 自車のボディから反射した点群を除去 21

22.

TIER IV AutowareのSensingモジュール (点群処理) crop_box_filter_self: 自車のミラーから反射した点群を除去 22

23.

TIER IV AutowareのSensingモジュール (点群処理) distortion_corrector: 自車が移動しつつLiDARが回転する由来の歪みを補正 23

24.

TIER IV AutowareのSensingモジュール (点群処理) ring_outlier_filter: 回転式LiDARの性質を生かした効率的な外れ値除去 24

25.

TIER IV 参考研究における手法 (再掲) ring_outlier_filter Reporter Reporter Bubble Bubble … Sensitivity Curve の算出 ring_outlier_filter … Contentiousness の算出 25

26.

TIER IV 計測の注意 : Isolatedに計測すべし ● Core Isolated = Timer割り込みが 入らないようにし, RCU Callbackを オフロード ● Fix Hz = CPUの周波数を常に一定 にする. Turbo BoostをOffにするこ とを忘れずに ● Core Affinity = IsolateしたCoreで は計測対象のプロセスを動作させる ● Reporter, 計測対象ノードは Isolate Isolated環境で動作 計測対象を動作させるノード 26

27.

TIER IV 手順1: Sensitivity Curve (Reporter, ring_outlier_filter) 時間がなくて ring_outlier_filter しか計測できなかった ... 27

28.

TIER IV 手順2: Contentiousness 負荷ベンチマークとしては「二分木の探索 (4MiB)」, ランダムアクセス (4, 8, 12MiB) を用意した 28

29.

TIER IV 予測精度の評価 29

30.

TIER IV 01 / 背景と概要 Autowareにおける リソース競合の定量化 TIER Ⅳ | Takahiro Ishikawa 02 / 参考研究の手法 03 / Autowareへの適用 04 / まとめ @sykwer 30

31.

TIER IV まとめ ● Autowareの時間性能面での予測可能性を高めるという目的で, メモリリソース競合 の定量化を目指した ● 仮説: タスク固有の「リソース競合への感応性」と「システムのリソースに与える負 荷」を定量化 → リアルタイムにリソース競合由来の遅延を算出可能 ● クラウド環境上で同様の考え方の手法を実現した先行研究を応用 ● Autowareのノードに対して手法を適用し, 十分な予測精度を出すことに成功 ● 今後の課題 1) 3つ以上のノードが同時にメモリ負荷をかけた場合 2) ノード自体の Contentiousness の算出 3) リソース競合由来の遅延予想をOSに実装 31

32.

TIER IV CONTACT US https://tier4.jp/ Thanks Again ! 32