輪講発表資料です。 The Multikernel: A new OS architecture for scalable multicore systems Andrew Baumann, Paul Barham, Pierre-Evariste Dagand, Tim Harris, Rebecca Isaacs, Simon Peter, Timothy Roscoe, Adrian Schüpbach, and Akhilesh Singhania SoSP09 An Analysis of Linux Scalability to Many Cores Silas Boyd-Wickizer, Austin T. Clements, Yandong Mao, Aleksey Pesterev, M. Frans Kaashoek, Robert Morris, and Nickolai Zeldovich MIT CSAIL OSDI10

1. 論文輪講(6/1)
The Multikernel: A new OS architecture for scalable multicore systems
&
An Analysis of Linux Scalability to Many Cores
あわもと

2. 論文概要
The Multikernel: A new OS architecture for scalable
multicore systems
SOSP09
MSのBarrelfish論文
メニーコア向けメッセージベースの独自分散OS

3. 論文概要
An Analysis of Linux Scalability to Many Cores
OSDI10
MIT CSAIL
Linuxもスケーラブルになるという主張

4. Introduction & Background (Barrelfish)
ハードウェアは急速に変化する。
コア、キャッシュ、インターコネクト、各種I/O
汎用的なOSを各ハードウェア向けに最適化するのは限界が
ある。
ex. アーキテクチャによってキャッシュの動作は異なる。
（それぞれに対して最適化したくない）
→ 新しい設計のOSが求められている。

5. Introduction & Background (Barrelfish)
今のOSのモデル
ロックでデータを保護する共有メモリ型の設計
homogeneousなCPUを想定
カーネルイメージは全コアで共有

6. Introduction & Background (Barrelfish)
multikernel：メニーコア向けの新しいOSモデル
全てのコア間の通信を明示的なメッセージで行う。
どんなハードウェアでも対応できるよう、ハードウェアに
依存しない中立的な設計
状態をコア間で共有せず、レプリケーションする。

7. Introduction & Background (Barrelfish)
multikernelモデルのメリット
ロックを使わず、共有するデータもない
メモリを共有すると、パフォーマンスが低下
コア同士でキャッシュラインをクリアし合う
コア間通信が発生
中立的な設計のため、アーキテクチャへの最適化が不要
homogeneous、heterogeneousの双方に対応可能
ネットワーク型メニーコアとの高い親和性

8. Introduction & Background (Linux)
メニーコア向けに様々なOSモデルが提唱されている。
既存のOSモデルでなんとかできないか検証したい。
Linuxにはこれまでにも、かなり性能改善のパッチが取り込
まれている。
ボトルネックの特定に関する様々な研究
run queue, slab allocator, I/O processings
scheduling, directory lookup
memory-mapped file creation and deletion
file descriptor, virtual memory management

9. Introduction & Background (Linux)
MOSBENCHで様々なアプリケーションを検証
Mail Server, memcached, Apache, PostgreSQL, gmake,
Psearchy, MapReduce
アプリケーションとLinuxの双方に手を加えてスケールアッ
プさせる。
sloppy countersでshared counterを置き換え
48コアで上手くスケールした。
カーネルに手を加えれば、既存のカーネルデザインのス
ケーラビリティは十分担保できる。

10. Implementation (Barrelfish)
カーネルに相当するCPU driver
Ring3で実行可能なタスクは全てMonitorへ
マイクロカーネル的な設計
CPU driver同士はステートを共有しない。←重要
IPIは他のコアを叩き起こすためにしか使われない？Monitor
管理用のユーザーランドプ
ロセス
カーネルの機能を補完
メッセージのやり取りも

11. Implementation (Barrelfish)
コア間通信
論文内のBarrelfishはx86-64実装のみ
通信はcache-coherent memory
recieverがメモリをpollingして、senderがメモリに書く。
IPI通信より早いらしい
スケジューリングの影響を受けるにも関わらず早く
なったとかなんとか。

12. Implementation (Barrelfish)
知見等
マイクロカーネルモデルにする事の利点はコードの書きやす
さのみ。性能向上には寄与しない。
既存のコードをスケーラブルになるよう改良するよりは、
共有データをメッセージベースに置き換える方がずっと
楽。
メッセージ・キューの長さと性能は大いに関係があるらし
い。

13. Evaluation (Barrelfish)
TLB shootdown
ページマッピングの変更を他のCPUに通知する作業
IPIではなく、メッセージを使用
低レイテンシ
IP loopback
２つのユーザーランドIPスタックをメッセージで接続
スループット上昇、キャッシュヒット率の向上etc…
共有データがないので、cache-coherent trafficが少ない。

14. Future Work (Barrelfish)
Barrelfish自体の改良
ARMポーティング
データをある程度共有するモデルの検証
どこまで共有できる？
その境界線の決定は自動化できる？
分散システムによって構築されるOS
HPCの技法を用いたスケーラブルなファイルシステム

15. Optimization (Linux)
Linuxカーネルにおけるスケーラビリティ阻害要因
共有データのロック
共有メモリへの書き込みによるキャッシュコヒーレンシプ
ロトコルの待ち時間
キャッシュミス率の上昇
コア間のインターコネクトやDRAMといったリソースの競
合
タスクが少なすぎる。

16. Optimization (Linux)
プロトコル・スタックの改善
各パケット、パケットプロセスキュー、コネクションが同
じコアは処理したい。
キャッシュミスの低下に繋がる。
ixgbeのマルチキューに問題
ixgbeドライバではパケットをサンプリングして割り振
りテーブルを構築する。
短いTCPコネクションはサンプリングから漏れる
acceptを改造して、コアバインディングインターフェー

17. Optimization (Linux)
Sloppy Counters

18. Optimization (Linux)
その他
Lock-free comparison
/usr 等のdirectory entryのlookupに時間が掛かる。
ロックせずにdentryを比較できるようにした。
コア毎のデータ構造
false sharingの低減
不必要なロックの除去

19. Evaluation (Linux)

20. Evaluation (Linux)
In each case, the application is bottlenecked by either
shared hardware resources or applicationinternal scalability
limits. None are limited by Linux induced bottlenecks.

21. Discussion & Conclusion (Linux)
Linuxカーネルのボトルネックは殆ど改善された。
むじろハードウェア(DRAM等)のボトルネックの方が改善
が難しい。
cache coherencyが保たれないアーキテクチャとなると流石
にLinuxの設計では厳しい。
Future workはLinuxに対してメニーコアOSの技法を適用す
る事。