昨夜FreeBSD勉強会に行ってきました。
前回の反省から、予習したからと言って気を緩めず直前の食事は軽目にしたのが正解だったようで、しっかり集中できました。個々の英文よりもまとめ的な話や重要なポイントの指摘をしっかり聞いてメモを残すことにしたのも良かったようです。今後はこのやり方で行こうと思います。
----- memo begin -----
Mutex Synchronization
・Mutexはスレッド間の同期等、短い期間に用いる。
・Mutexはブロックされるものとされないものがある。
・Spin MutexはCPUのループ。特定のコアを占有する。100～200ステップ程度ならスピンの方が軽いので限定された箇所に有効。
・Mutexが開放されたら待っている全スレッドを起こす。
・CPU内にコアが1つの時代はカーネル以外を動かなくするジャイアントロックで良かったがマルチコアでは効率が悪い。
・ディスクI/Oのような時間のかかるものにSpin Mutexはもったいない。Sleepすべき。
・コアが1つならSpin Mutexは無意味。Spinするとそれを起こすものがない。Sleepを使う。
Mutex Interface
・APIとしてどういう関数があってどう使うかが書いてあるので本セクションは必要になった時に参照すればよい。
Lock Synchronization
・Mutexはスレッドに対するロックに使うが、資源に対するロックはLockを使う。
・LockはMutexよりも抽象度が高い。
・共有ロックより排他ロックの方が強いロック。
・Table 4.3にあるwitnessは、複数種類があるロックを正しく使わずに(正しい使い方は明文化されていなかった)デッドロックを発生させてしまったのを監視して情報をコンソールに出力する。
・FreeBSD-currentはwitnessを有効にしてビルドされるのでコンソールに表示が出ることがある。witnessは重いがカーネル開発中には有効。
DeadLock Prevention
・Figure 4.4は2つのスレッドが資源獲得で競合してデッドロックになる例。
・デッドロックを起こさないために資源をクラスに分け、クラスはプライオリティを持ち、あるスレッドはあるクラス内で1つのみロックを獲得でき、別のクラスのロックもさらに獲得できるのはプライオリティがより高いクラスのみとした。これによりFigure 4.4の場合でもデッドロックは発生しない。
4.4 Thread Scheduling
・スケジューラは2つある。ULEスケジューラと4.4BSDスケジューラ。
・ULEの意味はおふざけ。scheduleをsched_uleとしただけ。
The Lowlevel Scheduler
・スケジューリングはローレベルとハイレベル2つに分かれる。
・ハイレベルスケジューラはコア毎にキューを持つ。
・スレッドがコアを移動するとキャッシュが効かなくなるので非効率。
・同じコアにいて、Context Switchingしない方が処理効率はよいがレスポンスが悪くなるのでタイムスライスの長さを適切に選択。
Thread Run Queues and Context Switching
・ランキューの走査時間を減らすため256/4=64にまとめた。
・マシン独立な部分とそうでない部分でmi_switch()とcpu_switch()に分離してある。cpu_switch()はアセンブラで記述。
・Context SwitchingはASTがサポートされていればハードで行う。
・システムコールはこれだけの時間走ったら切り替わるという限度がないのでバグがあればいつまでも走ってしまう。
TimeShare Thread Scheduling
・processor affinity: 効率のためできるだけ同じコアで動かしidleが動く時のみマイグレートする。
・1つのCPU内に複数のコアがある他に、1つのマザーボードに2つのCPUがある場合もある。
・スレッドが増えてもプライオリティの再計算が重くなり過ぎないようにULEスケジューラが開発された。
・ULEスケジューラはスレッドが今対話的(エディタ等)かバッチ的(コンパイラ等)かをinteractive scoreで管理していて挙動を変えている。自主的にsleepした回数、nice値等を使う。1msec刻みで過去10秒の統計情報を保持している。
----- memo end -----
前回の反省から、予習したからと言って気を緩めず直前の食事は軽目にしたのが正解だったようで、しっかり集中できました。個々の英文よりもまとめ的な話や重要なポイントの指摘をしっかり聞いてメモを残すことにしたのも良かったようです。今後はこのやり方で行こうと思います。
----- memo begin -----
Mutex Synchronization
・Mutexはスレッド間の同期等、短い期間に用いる。
・Mutexはブロックされるものとされないものがある。
・Spin MutexはCPUのループ。特定のコアを占有する。100～200ステップ程度ならスピンの方が軽いので限定された箇所に有効。
・Mutexが開放されたら待っている全スレッドを起こす。
・CPU内にコアが1つの時代はカーネル以外を動かなくするジャイアントロックで良かったがマルチコアでは効率が悪い。
・ディスクI/Oのような時間のかかるものにSpin Mutexはもったいない。Sleepすべき。
・コアが1つならSpin Mutexは無意味。Spinするとそれを起こすものがない。Sleepを使う。
Mutex Interface
・APIとしてどういう関数があってどう使うかが書いてあるので本セクションは必要になった時に参照すればよい。
Lock Synchronization
・Mutexはスレッドに対するロックに使うが、資源に対するロックはLockを使う。
・LockはMutexよりも抽象度が高い。
・共有ロックより排他ロックの方が強いロック。
・Table 4.3にあるwitnessは、複数種類があるロックを正しく使わずに(正しい使い方は明文化されていなかった)デッドロックを発生させてしまったのを監視して情報をコンソールに出力する。
・FreeBSD-currentはwitnessを有効にしてビルドされるのでコンソールに表示が出ることがある。witnessは重いがカーネル開発中には有効。
DeadLock Prevention
・Figure 4.4は2つのスレッドが資源獲得で競合してデッドロックになる例。
・デッドロックを起こさないために資源をクラスに分け、クラスはプライオリティを持ち、あるスレッドはあるクラス内で1つのみロックを獲得でき、別のクラスのロックもさらに獲得できるのはプライオリティがより高いクラスのみとした。これによりFigure 4.4の場合でもデッドロックは発生しない。
4.4 Thread Scheduling
・スケジューラは2つある。ULEスケジューラと4.4BSDスケジューラ。
・ULEの意味はおふざけ。scheduleをsched_uleとしただけ。
The Lowlevel Scheduler
・スケジューリングはローレベルとハイレベル2つに分かれる。
・ハイレベルスケジューラはコア毎にキューを持つ。
・スレッドがコアを移動するとキャッシュが効かなくなるので非効率。
・同じコアにいて、Context Switchingしない方が処理効率はよいがレスポンスが悪くなるのでタイムスライスの長さを適切に選択。
Thread Run Queues and Context Switching
・ランキューの走査時間を減らすため256/4=64にまとめた。
・マシン独立な部分とそうでない部分でmi_switch()とcpu_switch()に分離してある。cpu_switch()はアセンブラで記述。
・Context SwitchingはASTがサポートされていればハードで行う。
・システムコールはこれだけの時間走ったら切り替わるという限度がないのでバグがあればいつまでも走ってしまう。
TimeShare Thread Scheduling
・processor affinity: 効率のためできるだけ同じコアで動かしidleが動く時のみマイグレートする。
・1つのCPU内に複数のコアがある他に、1つのマザーボードに2つのCPUがある場合もある。
・スレッドが増えてもプライオリティの再計算が重くなり過ぎないようにULEスケジューラが開発された。
・ULEスケジューラはスレッドが今対話的(エディタ等)かバッチ的(コンパイラ等)かをinteractive scoreで管理していて挙動を変えている。自主的にsleepした回数、nice値等を使う。1msec刻みで過去10秒の統計情報を保持している。
----- memo end -----