Hidehito Yabuuchi Bachelor Thesis

1. 非対称マルチコアアーキテクチャにおける
スループット指向マルチカーネルの設計と実装
Throughput-Oriented Multikernel Design and Implementation
for Heterogeneous Multi-Core Architecture
2018/02/13 卒業論文発表
理学部情報科学科4年
加藤研究室 薮内秀仁

2. 背景
組込みシステムの特徴
● 各プロセスの負荷に大きなばらつき
● 電力効率が重要
非対称マルチコアアーキテクチャの採用
● Large core：計算性能に重点
● Small core：電力効率に特化
e.g. ARM big.LITTLE, Kalray MPPA Processors
2

3. 3
既存研究
全体のスループット向上
[Koufaty+, '10], [Saez+, '10], [Craeynest+, '12], [Muthukaruppan+, '14]
● 動的なタスクマイグレーション
◎ アプリケーションの挙動の変化に対応
✕ タスクマイグレーションのコスト
● マルチタスキング・カーネルの共有
◎ 既存OSと同じインターフェイス
✕ プリエンプション・排他制御のコスト

4. 提案するOS設計
Multikernelモデル [Baumann+, '09] の適用
Large coreを専有的に割り当て
● プリエンプションを回避
● タスクマイグレーションを回避
● 排他制御を回避
4

5. 提案するOS設計
動的な
アイソレーション・
ブート
Home kernelが
全コアで動作
5

6. 提案するOS設計
Friend kernelの性質
● マルチタスキング不要
● それぞれのfriend processに特化可能
Library OSアプローチ[Engler+, '95] を採用
● カーネルのオーバーヘッド削減
● 全体の最適化
6Icon made by Freepik from www.flaticon.com

7. 実装
Home Kernel
● Linux（4.14-rc7ベース）
● カーネルモジュール (LKM) を実装
Friend Kernel & Process
コンパイル・静的リンク
実行ファイルをパース・再配
置物理メモリにデプロイ
ユーザの操作でfriend coreをブート
7Icon made by Freepik from www.flaticon.com

8. 評価環境
HiKey 960 開発ボード (Kirin 960 SoC)
● ARM big.LITTLE
○ 2.4 GHz ARM Cortex-A73 x 4
Large core
○ 1.8 GHz ARM Cortex-A53 x 4
Small core
● 4 GB SDRAM
Image from
https://www.96boards.org/product/hikey960/
8

9. 評価
比較対象
● 提案するOS
● Linux
評価に用いたプロセス
● 共有資源にアクセスしないプロセス
● 共有資源にアクセスするプロセス
9

10. 10%以上
10

11. 考察
提案するOSのほうが速くなる条件
オーバーヘッド オーバーヘッド
11

12. 仮定
c = 0.9
S < 16 MB
提案するOSが
速くなる条件
T > 1970 ms
12

13. 13
結論
● 非対称マルチコアアーキテクチャ上で
特定プロセスのスループットを改善するOS設計を提案
● 評価の範囲ではLinuxに比べスループットが10%以上改善
● スループットの改善と初期化・終了処理のトレードオフ関係を調査し
仮定のもと「Linux上での実行時間 > 1970 ms」で有用であることを解明
今後の課題
Unikernels [Madhavapeddy+, '13] をfriend kernelとして使えないか検討
● 軽量で起動が速い
● Large coreの計算性能を有効活用

14. 14
補足

15. 15
プリエンプション・タスクマイグレーションのコスト
Cache affinityの喪失によりキャッシュミス頻発[Bastoni+, '10]
補足
ワーキングセッ
ト サイズ [KB]
プリエンプション[us] タスク
マイグレーション[us]
負荷下
1,024 3,485.44 3,935.43
4,096 12,936.70 15,078.12
アイドル状態
1,024 30.03 784.89
4,096 283.65 1,169.90

16. 関連研究
Multikernel [Baumann+, '09]
分散型・メッセージパッシング型OS設計
● 各コアで別々のカーネルが動作
● カーネルの状態を共有せず
レプリケーション・明示的な通信
利点
● スケーラビリティ向上
● ヘテロなアーキテクチャに対応
Image from:
Andrew Baumann, et al. The Multikernel: A new OS
architecture for scalable multicore systems. SOSP '09
16
補足

17. 17
関連研究
Decoupling Cores, Kernels, and OS [Zellweger+, '14]
コアとカーネルの分離による動的なコア・カーネル管理
● コアを動的・透過的に追加・削除
● ダウンタイムなしでカーネルの更新・マイグレーション
補足

18. 実装
Friend Processの起動
1. カーネルモジュール (LKM) をインストール(insmod)
a. cpu_down() でlarge coreをLinuxから分離
b. キャラクタデバイス、sysfs objectを生成
2. キャラクタデバイスを通してfriend processをデプロイ
3. Sysfs objectに書き込んでfriend coreをブート
ARM Power State Coordination Interface (PSCI) を利用
4. LKMを削除 (rmmod)
a. キャラクタデバイス、sysfs objectを削除
b. cpu_up() でfriend coreをLinuxに復帰
18
補足

19. 19
実装
HomeとFriendの通信
カーネル間で状態を共有しないため明示的に通信
事前に取り決めた物理メモリ領域を利用
補足

20. 20
評価
Linux上でのアイソレーション
1. ブートパラメータでコアをスケジューラから分離
2. 評価対象のプロセスのみアイソレーションしたコア上で動くよう
CPU affinityを設定
補足

21. 評価
共有資源にアクセスしないプロセス
一定時間カウントアッ
プできた回数を測定
Linux上でのアイソレーション
、Friend process共通して
スループットは落ちないと予測
補足
21

22. 補足
22

23. 評価
共有資源にアクセスするプロセス
「スリープ＋計算」を繰り返した
経過時間を測定
● Linuxではnanosleep(2)時に
共有資源にアクセス
○ 負荷によりスループットが
低下すると予測
● Friend processは共有しない
○ スループットは低下しないと予測
補足
23

24. 考察
Tins + Tboot + Trem の測定
● カーネルモジュールのインストール・削除にかかる時間
● Friend coreをブートしてからmain()に到達するまでの時間
デプロイ時間 d(S) の測定
ユーザー空間からメモリ上にコピーされるまでの時間
補足
24

25. 考察
Tins + Tboot + Trem の測定
補足
25

26. 考察
デプロイ時間 d(S) の測定
補足
26

27. 考察
実行モデル
測定結果
代入
補足
27

28. 28
考察
Friend processのファイルサイズ
補足
ELFファイルサイズ Friend processへ変換後
評価に用いたプロセス 67 KB 1.4 KB
BusyBox 1.5 MB 1.5 MB

29. 29
評価・考察
測定回数
● スループットの改善
○ 共有資源にアクセスしないプロセス：256回
○ 共有資源にアクセスするプロセス：256回
● 考察
○ LKMのインストール：512回
○ LKMの削除：512回
○ Friend coreのブート：32回
○ デプロイ時間：256回
補足

30. 30
今後の課題
Unikernels [Madhavapeddy+, '13]
Library OSとプロセスをVMにコンパイル
● 軽量・起動が高速
○ 組込みでも有用 [Madhavapeddy+, '15]
● カーネル・ユーザー空間統一
○ Large coreの計算性能を有効活用
Rumprun unikernel [Kantee+, '14] はベアメタルでも動作
補足