Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
1
FlexSC-Threadsの紹介
プログラムの変更無しに
マルチスレッドプロセスを高速化
V0.9.4
2015/10/27
Satoru Takeuchi
<satoru.takeuchi@gmail.com>
2
はじめに
●
本書の目的
● “FlexSC: Flexible System Call Scheduling with
Exception-Less System Calls”[1]という論文に
記載されているFlexSC-Threads...
3
注意点
●
本書に記載の数値やグラフは単純化してある
●
正確なところを知りたければ、元論文を参照
してほしい
●
元論文以上の知識は得られないので、元論文を
最初から理解できるような人は対象外
●
本書の中に記載されている「性能」とは、と...
4
目次
1.FlexSC-Threadsとは
2.前提知識
3.動作のしくみ
4.実装
5.まとめ
6.参考文献
5
FlexSC-Threadsとは: 概要
● Linuxのマルチスレッドプロセスを高速化する
pthread互換ライブラリ
● 使い方: pthreadライブラリとしてFlexSC-
Threadsをリンク
●
プログラムの変更は不要
6
FlexSC-Threadsとは: 効果と適用範
囲
●
性能向上の例
● Apache: 116%Up
● MySQL: 40%Up
● BIND: 105%Up
●
性能向上が見込める条件
●
スレッド数が多い
●
システムコールの呼び...
7
FlexSC-Threadsとは: 着想
●
後述の、ユーザモードとカーネルモードの間の
状態遷移(以下、状態遷移と記載)の数を極力減ら
すことによって性能向上を図る
1.状態遷移の頻度が減少
2.キャッシュフラッシュの頻度減少
3.キャッ...
8
FlexSC-Threadsとは: 現在の状況
● glibcに実装しようとした計画もかつては存在
●
その後音沙汰が無いので、立ち消えになった
模様
● 自前で実装してみた人もいるらしい[2]
●
筆者は動作確認をしていないため、まともに...
9
前提知識(1/3): システムコール発行
時の状態遷移
●
プロセスがシステムコールを発行するたびに状
態遷移が2回発生
ユーザモード
カーネルモード
状態遷移
ユーザのための
システムコールを処理
カーネルから割り当てられた
一部システム...
10
前提知識(1/3): キャッシュメモリの
フラッシュ
●
状態遷移のたびにキャッシュメモリがフラッ
シュされる
ユーザモード
カーネルモード
キャッシュの
フラッシュ
キャッシュの
フラッシュ
11
前提知識(1/3): キャッシュフラッ
シュの悪影響
●
キャッシュフラッシュからしばらくキャッシュ
ヒット率が下がるため、性能劣化
性能
システムコール発行
からの経過時間
トータルでは斜線部分の
面積だけ性能劣化
12
前提知識(1/3): 短時間に多くのシス
テムコールを発行した場合
●
低い性能のまま時間が経過
性能(単位時間
あたりの
命令実行数)
経過時間
ユーザモード
カーネルモード
トータルでは斜線部分の
面積だけ性能劣化
13
前提知識(2/3): スレッドモデル
●
スレッドを実装する方法
● 1x1モデル: スレッドとカーネル内のスケ
ジューリング対象が1:1に対応
● glibcのデフォルトpthreadライブラリ
(NPTL)はこれ
● Mx1モデル: ...
14
前提知識(2/3): 時分割によるプロセ
スの並行処理
● 1CPU上に複数プロセスが存在する場合、各プロ
セスが一定時間ごとに、順番にCPUを使用
● 例) p1, p2, p3の3つのプロセスが存在
● 全プロセスがCPUを使う処理の...
15
前提知識(2/3): 並行処理時の状態遷
移
● 実はCPU上で動作するプロセスが変化するたび
に状態遷移が起き、カーネル上のスケジューラ
という処理が動作(*1)
●
スケジューラは次にどのプロセスを動かすか
を決定(詳細は割愛)
●
...
16
前提知識(2/3): 1x1モデルにおけるス
レッドの並行処理
● 例) 3スレッドt1, t2, t3が存在する場合
● 全スレッドがCPUを使う処理のみ実行
●
結果は複数プロセスが存在する場合と同じ
●
そのたびに性能劣化
CPU上...
17
前提知識(2/3): Mx1モデルにおける
スレッドの並行処理
● 例) 3スレッドt1, t2, t3が存在する場合
● 全スレッドがCPUを使う処理のみ実行
● CPU上で別スレッドが動き出す際に状態遷移が
発生しない
● 理由: M...
18
前提知識(3/3): システムコールの
ラッパ関数
● 通常、システムコールはlibcのラッパ関数を介し
て呼び出す
●
直接呼び出すにはアセンブリ言語を使う必要
があり、移植性が無い
ユーザプロセス
直接呼び出し
移植性なし
アーキテク...
19
動作のしくみ: 前置き
● 簡単のため、1CPUの場合について説明
● 複数CPUの場合でも基本的には同じ
● ここでいう複数CPUとは、複数コア、複数ス
レッドの場合も含む
20
動作のしくみ: NPTLにおける複数ス
レッドの動作
● スレッドモデルは1x1
● 例) 複数スレッドt1, t2, t3がCPU上で動作するた
びにシステムコールを発行
●
簡単のため、システムコールがブロックされ
る場合は考えない
...
21
動作のしくみ: FlexSC-Threads
● Mx1スレッドモデル
●
システムコール発行時の処理が以下のように変
わる
1.各スレッドのシステムコール要求を一旦溜め
ておく
2.所定のタイミング(後述)で、システムコール
を連続実行
22
動作のしくみ: FlexSC-Threadsにお
ける複数スレッドの動作
● 例) 複数スレッドt1, t2, t3がCPU上で動作するた
びにシステムコールを発行
●
状態遷移の数が激減することによって性能向上
● Mx1モデルなので、...
23
動作のしくみ: 複数CPUの場合
● 全CPUに同じ処理が並ぶだけ(図は2CPUの場合)
● カーネル処理がCPUの数存在するので、ス
レッドモデルはM(スレッド数)xN(CPU数)
CPU2上で動
作中の処理
カーネルモード(スケジュー...
24
動作のしくみ: さらなる性能向上
● スレッドがn本あれば、n回のシステムコール発
行につき2回だけ状態遷移
●
スレッド数が多くなるほど、システムコール呼
び出し頻度が高くなるほど、システムコールを
連続実行できる頻度が向上し、さらなる...
25
実装: 概要
●
前述のしくみを実現するために、以下の作り込
みが必要
● カーネル: 新規システムコールの追加
●
初期化用
● システムコールの連続実行用(以下、連続実
行用と記載)
● FlexSC-Threads: 新規作成
●
...
26
実装: 初期化用システムコール
●
連続実行用システムコールを使用可能にする
1.ユーザとカーネルの共有メモリを作成し、前
述のキューとして使用
●
キュー内エントリのデータ構造
●
システムコール実行に必要なパラメタ
●
システムコール...
27
実装: 連続実行用システムコール
1.キューから取り出した全エントリについて、以
下の処理を実行
1.1.システムコールを実行
1.2.実行したシステムコールの戻り値を、該当
するキューのエントリに書き込む
1.3.終了状態を更新
2.キ...
28
実装: システムコールのラッパ関数
キューにシステムコールのパラメタを書いたエントリを挿入
キューが一杯?
連続実行用システム
コールを呼び出す
他に実行可能な
スレッドが存在?
他のスレッドにCPU
実行権を明け渡す
自身の戻り値を必要...
29
実装: pthreadライブラリ関数
●
カーネルの助け無しに、ライブラリ内だけでス
レッド制御の仕組みを作成
● 理由: スレッドモデルがMx1
30
実装: FlexSC-Threadsの動的リンク
●
動的リンクをすれば準備完了
●
連続実行用システムコールが使用可能になる
● libc提供のラッパ関数を上書き
● pthreadライブラリ関数を上書き
●
プログラムのバイナリ変更は...
31
複数CPUの場合
● キューとカーネル処理がCPUごとに存在するだ
けで、後は1CPUの場合と一緒
● キューがCPUごとに存在するため、排他制御は
不要
●
スケーラビリティあり
32
まとめ: ユーザから見た変化
● libcのインターフェイスは全く変更が無いため、
プログラムは変更不要
● スレッドモデルの変更に伴い/proc/<pid>/以下
の見え方が変わるため、そこに依存するよう
な処理をしている場合には考慮が...
33
まとめ: 使用するにあたって
● システムコールの発行数が少ない or スレッド数
が少ない場合、期待に反して性能劣化する可能
性あり
●
とくにシングルスレッドの場合、システムコー
ル発行毎に連続実行用システムコールを発行
するため、使...
34
まとめ: 個人的な感想
● レイテンシの最悪値/中央値/最良値も見てみたい
●
元論文中にはスループットと平均レイテンシ
についての情報のみ
●
個々のレイテンシを重要視するようなシステ
ムにも適用できるか否かを確認したい
● 原理的には...
35
参考文献
1.Livio Soares and Michael Stumm. FlexSC:
Flexible System Call Scheduling with Exception-
Less System Calls
http:/...
Nächste SlideShare
Wird geladen in …5
×

FlexSC-Threadsの紹介 -プログラムの変更無しにマルチスレッドプロセスを高速化

プログラムの変更なしにマルチスレッドプロセスを高速化するpthread互換ライブラリ、FlexSC-Threadsを紹介

FlexSC-Threadsの紹介 -プログラムの変更無しにマルチスレッドプロセスを高速化

  1. 1. 1 FlexSC-Threadsの紹介 プログラムの変更無しに マルチスレッドプロセスを高速化 V0.9.4 2015/10/27 Satoru Takeuchi <satoru.takeuchi@gmail.com>
  2. 2. 2 はじめに ● 本書の目的 ● “FlexSC: Flexible System Call Scheduling with Exception-Less System Calls”[1]という論文に 記載されているFlexSC-Threadsの紹介 ● 執筆動機 ● FlexSC-Threadsは機能の効果、実装ともに かっこいいので、多くの人に知ってもらいた かった ● 元論文を読むのに必要なOS、とくにスケ ジューラ)の知識が無くても読める、副読本を 作りたかった
  3. 3. 3 注意点 ● 本書に記載の数値やグラフは単純化してある ● 正確なところを知りたければ、元論文を参照 してほしい ● 元論文以上の知識は得られないので、元論文を 最初から理解できるような人は対象外 ● 本書の中に記載されている「性能」とは、とく に断りがなければCPUのInstrction per secondの こと
  4. 4. 4 目次 1.FlexSC-Threadsとは 2.前提知識 3.動作のしくみ 4.実装 5.まとめ 6.参考文献
  5. 5. 5 FlexSC-Threadsとは: 概要 ● Linuxのマルチスレッドプロセスを高速化する pthread互換ライブラリ ● 使い方: pthreadライブラリとしてFlexSC- Threadsをリンク ● プログラムの変更は不要
  6. 6. 6 FlexSC-Threadsとは: 効果と適用範 囲 ● 性能向上の例 ● Apache: 116%Up ● MySQL: 40%Up ● BIND: 105%Up ● 性能向上が見込める条件 ● スレッド数が多い ● システムコールの呼び出し頻度が高い
  7. 7. 7 FlexSC-Threadsとは: 着想 ● 後述の、ユーザモードとカーネルモードの間の 状態遷移(以下、状態遷移と記載)の数を極力減ら すことによって性能向上を図る 1.状態遷移の頻度が減少 2.キャッシュフラッシュの頻度減少 3.キャッシュヒット率向上 4.性能向上
  8. 8. 8 FlexSC-Threadsとは: 現在の状況 ● glibcに実装しようとした計画もかつては存在 ● その後音沙汰が無いので、立ち消えになった 模様 ● 自前で実装してみた人もいるらしい[2] ● 筆者は動作確認をしていないため、まともに 動くかどうかは不明
  9. 9. 9 前提知識(1/3): システムコール発行 時の状態遷移 ● プロセスがシステムコールを発行するたびに状 態遷移が2回発生 ユーザモード カーネルモード 状態遷移 ユーザのための システムコールを処理 カーネルから割り当てられた 一部システムリソースしか使えない システムリソースを 全て利用可能
  10. 10. 10 前提知識(1/3): キャッシュメモリの フラッシュ ● 状態遷移のたびにキャッシュメモリがフラッ シュされる ユーザモード カーネルモード キャッシュの フラッシュ キャッシュの フラッシュ
  11. 11. 11 前提知識(1/3): キャッシュフラッ シュの悪影響 ● キャッシュフラッシュからしばらくキャッシュ ヒット率が下がるため、性能劣化 性能 システムコール発行 からの経過時間 トータルでは斜線部分の 面積だけ性能劣化
  12. 12. 12 前提知識(1/3): 短時間に多くのシス テムコールを発行した場合 ● 低い性能のまま時間が経過 性能(単位時間 あたりの 命令実行数) 経過時間 ユーザモード カーネルモード トータルでは斜線部分の 面積だけ性能劣化
  13. 13. 13 前提知識(2/3): スレッドモデル ● スレッドを実装する方法 ● 1x1モデル: スレッドとカーネル内のスケ ジューリング対象が1:1に対応 ● glibcのデフォルトpthreadライブラリ (NPTL)はこれ ● Mx1モデル: 同、M(スレッド数):1に対応 ● 1CPUのFlexSC-Threadsはこれ ● MxNモデル: 同、MxNに対応 ● 複数CPUのFlexSC-Threadsはこれ ● どれも一長一短 ● 以降、1x1とMx1について図解説明
  14. 14. 14 前提知識(2/3): 時分割によるプロセ スの並行処理 ● 1CPU上に複数プロセスが存在する場合、各プロ セスが一定時間ごとに、順番にCPUを使用 ● 例) p1, p2, p3の3つのプロセスが存在 ● 全プロセスがCPUを使う処理のみ実行 CPU上で動作 中の処理 時刻経過 p1 p2 p3 p1 p2
  15. 15. 15 前提知識(2/3): 並行処理時の状態遷 移 ● 実はCPU上で動作するプロセスが変化するたび に状態遷移が起き、カーネル上のスケジューラ という処理が動作(*1) ● スケジューラは次にどのプロセスを動かすか を決定(詳細は割愛) ● そのたび性能劣化 CPU上で動作 中の処理 カーネルモード p1 ユーザモード p2 p3 p1 p2 時刻経過 *1) 簡単のため、個々のタイマ 割り込みによる状態遷移は無視
  16. 16. 16 前提知識(2/3): 1x1モデルにおけるス レッドの並行処理 ● 例) 3スレッドt1, t2, t3が存在する場合 ● 全スレッドがCPUを使う処理のみ実行 ● 結果は複数プロセスが存在する場合と同じ ● そのたびに性能劣化 CPU上で動作 中の処理 カーネルモード t1 ユーザモード t2 t3 t1 t2 時刻経過
  17. 17. 17 前提知識(2/3): Mx1モデルにおける スレッドの並行処理 ● 例) 3スレッドt1, t2, t3が存在する場合 ● 全スレッドがCPUを使う処理のみ実行 ● CPU上で別スレッドが動き出す際に状態遷移が 発生しない ● 理由: Mx1モデルはユーザ空間でスレッドのス ケジューリングをしている CPU上で動作 中の処理 カーネルモード t2 ユーザモード 時刻経過 t1 t3 t1 t2
  18. 18. 18 前提知識(3/3): システムコールの ラッパ関数 ● 通常、システムコールはlibcのラッパ関数を介し て呼び出す ● 直接呼び出すにはアセンブリ言語を使う必要 があり、移植性が無い ユーザプロセス 直接呼び出し 移植性なし アーキテクチャ依存 アセンブリ言語で書く libcのラッパ関数呼び出し Cで書く libc経由で呼び出し 移植性あり アーキテクチャ依存 アセンブリ言語で書く libcのラッパ関数
  19. 19. 19 動作のしくみ: 前置き ● 簡単のため、1CPUの場合について説明 ● 複数CPUの場合でも基本的には同じ ● ここでいう複数CPUとは、複数コア、複数ス レッドの場合も含む
  20. 20. 20 動作のしくみ: NPTLにおける複数ス レッドの動作 ● スレッドモデルは1x1 ● 例) 複数スレッドt1, t2, t3がCPU上で動作するた びにシステムコールを発行 ● 簡単のため、システムコールがブロックされ る場合は考えない ● 大量の状態遷移が発生 CPU上で動作 中の処理 カーネルモード(スケジューラ) ユーザモード 時刻経過 t1 カーネルモード(システムコール処理) t1 t2t2 t3t3 t1t1
  21. 21. 21 動作のしくみ: FlexSC-Threads ● Mx1スレッドモデル ● システムコール発行時の処理が以下のように変 わる 1.各スレッドのシステムコール要求を一旦溜め ておく 2.所定のタイミング(後述)で、システムコール を連続実行
  22. 22. 22 動作のしくみ: FlexSC-Threadsにお ける複数スレッドの動作 ● 例) 複数スレッドt1, t2, t3がCPU上で動作するた びにシステムコールを発行 ● 状態遷移の数が激減することによって性能向上 ● Mx1モデルなので、CPU上で動作するスレッ ドが変わっても状態遷移無し ● システムコールの発行は3回に1回で済む CPU上で動作 中の処理 カーネルモード(スケジューラ) ユーザモード 時刻経過 カーネルモード(システムコール処理) t1 t2 t3 t1 t2 t3 t1 t2 t3 t1, t2, t3用の システムコールを 連続実行
  23. 23. 23 動作のしくみ: 複数CPUの場合 ● 全CPUに同じ処理が並ぶだけ(図は2CPUの場合) ● カーネル処理がCPUの数存在するので、ス レッドモデルはM(スレッド数)xN(CPU数) CPU2上で動 作中の処理 カーネルモード(スケジューラ) ユーザモード 時刻経過 カーネルモード(システムコール処理) t4 t5 t6 t4 t5 t6 t4 t5 t6 CPU1上で動 作中の処理 t1 t2 t3 t1 t2 t3 t1 t2 t3
  24. 24. 24 動作のしくみ: さらなる性能向上 ● スレッドがn本あれば、n回のシステムコール発 行につき2回だけ状態遷移 ● スレッド数が多くなるほど、システムコール呼 び出し頻度が高くなるほど、システムコールを 連続実行できる頻度が向上し、さらなる性能向 上が期待できる
  25. 25. 25 実装: 概要 ● 前述のしくみを実現するために、以下の作り込 みが必要 ● カーネル: 新規システムコールの追加 ● 初期化用 ● システムコールの連続実行用(以下、連続実 行用と記載) ● FlexSC-Threads: 新規作成 ● ロード時に初期化用システムコールを呼び 出す ● システムコールのラッパ関数 ● pthreadライブラリ関数
  26. 26. 26 実装: 初期化用システムコール ● 連続実行用システムコールを使用可能にする 1.ユーザとカーネルの共有メモリを作成し、前 述のキューとして使用 ● キュー内エントリのデータ構造 ● システムコール実行に必要なパラメタ ● システムコールの終了状態 ● 戻り値 2.プロセスにキューのアドレスを返す
  27. 27. 27 実装: 連続実行用システムコール 1.キューから取り出した全エントリについて、以 下の処理を実行 1.1.システムコールを実行 1.2.実行したシステムコールの戻り値を、該当 するキューのエントリに書き込む 1.3.終了状態を更新 2.キューが空になったらユーザモードに復帰
  28. 28. 28 実装: システムコールのラッパ関数 キューにシステムコールのパラメタを書いたエントリを挿入 キューが一杯? 連続実行用システム コールを呼び出す 他に実行可能な スレッドが存在? 他のスレッドにCPU 実行権を明け渡す 自身の戻り値を必要箇所に書き込んだ上で次の処理に進む システムコールが完了済の スレッドを全て起こす 他のスレッドの システムコールが 完了済? YesNo No Yes No Yes
  29. 29. 29 実装: pthreadライブラリ関数 ● カーネルの助け無しに、ライブラリ内だけでス レッド制御の仕組みを作成 ● 理由: スレッドモデルがMx1
  30. 30. 30 実装: FlexSC-Threadsの動的リンク ● 動的リンクをすれば準備完了 ● 連続実行用システムコールが使用可能になる ● libc提供のラッパ関数を上書き ● pthreadライブラリ関数を上書き ● プログラムのバイナリ変更は不要 ● 以下の場合はFlexSC-Threadsの恩恵を受けられ ない ● libcを静的リンクしている ● libc提供のラッパ関数経由でシステムコールを 呼んでいない
  31. 31. 31 複数CPUの場合 ● キューとカーネル処理がCPUごとに存在するだ けで、後は1CPUの場合と一緒 ● キューがCPUごとに存在するため、排他制御は 不要 ● スケーラビリティあり
  32. 32. 32 まとめ: ユーザから見た変化 ● libcのインターフェイスは全く変更が無いため、 プログラムは変更不要 ● スレッドモデルの変更に伴い/proc/<pid>/以下 の見え方が変わるため、そこに依存するよう な処理をしている場合には考慮が必要 ● スレッドライブラリの入れ替えだけで性能向上 ● システム標準のlibc(通常glibc)が対応していれ ば、環境変数の設定など、より簡単な方法で FlexSC-Threadsを使用できるようになるかも
  33. 33. 33 まとめ: 使用するにあたって ● システムコールの発行数が少ない or スレッド数 が少ない場合、期待に反して性能劣化する可能 性あり ● とくにシングルスレッドの場合、システムコー ル発行毎に連続実行用システムコールを発行 するため、使う意味がない ● 使用可否の判断をする前の性能実測が必須
  34. 34. 34 まとめ: 個人的な感想 ● レイテンシの最悪値/中央値/最良値も見てみたい ● 元論文中にはスループットと平均レイテンシ についての情報のみ ● 個々のレイテンシを重要視するようなシステ ムにも適用できるか否かを確認したい ● 原理的には他のOSでも実装可能なので、やって みると面白いかも
  35. 35. 35 参考文献 1.Livio Soares and Michael Stumm. FlexSC: Flexible System Call Scheduling with Exception- Less System Calls http://www.cs.cmu.edu/~chensm/Big_Data_rea ding_group/papers/flexsc-osdi10.pdf 2.Github ID “spinlock”. implements flexsc (flexiable system call, OSDI '10) on ubuntu https://github.com/spinlock/flexsc

×