[試して理解] Linuxのプロセススケジューラのしくみ

Slide 1

Slide 1 text

[試して理解] Linuxのプロセススケジューラのしくみ Nov. 10, 2018 Satoru Takeuchi Twitter: @satoru_takeuchi 1

Slide 2

Slide 2 text

はじめに ● Linuxのスケジューラのしくみを紹介 ○ カーネルソースを一切見ずに図解と実験によって確認 ● 用語 ○ タスク: カーネルのスケジューリング単位。プロセスまたはスレッド ○ LCPU: カーネルがCPUとして認識するもの(物理CPU or コア or スレッド) ● 実験環境 ○ ハードウェア ■ CPU: Ryzen 1800x (8 core, 16 thread => 16LCPU) ○ ソフトウェア ■ Ubuntu 18.04 ■ Kernel v4.15.0-34-generic 2

Slide 3

Slide 3 text

ランキュー ● 実行可能タスク(ここではt0, t1, t2)をつないでおくキュー 3 LCPU t0 t1 t2

Slide 4

Slide 4 text

ラウンドロビンスケジューリング ● ランキューにつながるタスクに順番にCPU時間を与える 4 LCPU t0 t1 t2 LCPU t1 t2 t0 LCPU t2 t0 t1 current

Slide 5

Slide 5 text

ラウンドロビンスケジューリング ● 時刻経過に伴うcurrentの変化 5 t0 t1 t2 t0 t1 t2 時間 current

Slide 6

Slide 6 text

前振り: 詳解Linuxカーネル第三版曰く… ● ランキューはactiveキューとinactiveキューの二本 ● タスクの優先度は動的に変化する ● タスクごとのタイムスライスは100ms 6

Slide 7

Slide 7 text

前振り: 詳解Linuxカーネル第三版曰く… ● ランキューはactiveキューとinactiveキューの二本 ● タスクの優先度は動的に変化する ● タスクごとのタイムスライスは100ms 7 ● 今は全然違う ● 約11年前にスケジューラは殆ど全て書き直されている ● O(1)スケジューラ -> Completely Fair Scheduler(CFS)

Slide 8

Slide 8 text

もくじ ● スケジューラ ● ロードバランサ ● Fair Share Scheduler ● CFS Bandwidth Controller 8

Slide 9

Slide 9 text

まずは1LCPUから ● 16個のLCPUのうち15個をオフラインにする ● CPUホットプラグという機能を利用 ● これで論理的に「1コア1スレッド」のシステムになる 9 # grep -c processor /proc/cpuinfo 16 # for ((i=1;i<16;i++)) ; do > echo 0 >/sys/devices/system/cpu/cpu${i}/online > done # grep -c processor /proc/cpuinfo 1 #

Slide 10

Slide 10 text

CFSのスケジューリングのしくみ ● ラウンドロビンスケジューリング ● 各タスクはレイテンシターゲットと呼ばれる期間に一度CPU時間を得られる ○ 数ms～数十ms。カーネルバージョンによって変わる ○ sysctlのkernel.sched_latency_nsパラメタ(ns単位) ● タイムスライス = レイテンシターゲット/実行可能タスク数 10 $ sysctl kernel.sched_latency_ns kernel.sched_latency_ns = 6000000 # 6ms $

Slide 11

Slide 11 text

LCPU上で動くタスク 11 タスク数2 タスク数3 タスク数4 時間 t0 t1 t0 t1 t0 t1 t2 t0 t1 t2 t0 t1 t2 t3 t0 t1 t2 t3 レイテンシターゲットレイテンシターゲット

Slide 12

Slide 12 text

スケジューラの挙動: 初期状態 ● 仮定 ○ レイテンシターゲット : 6 [ms] ● タイムスライス＝6/(runnableタスク数=3) [ms] 12 0 0 0 t0 t1 t2 vruntime(簡単のため簡略化している ) LCPU ランキュー(vruntime順にソートされた赤黒木 )

Slide 13

Slide 13 text

ランキュー先頭のタスクをcurrentに 13 0 0 t1 t2 LCPU 0 t0

Slide 14

Slide 14 text

タイムスライス切れまで動かす ● 6/3=2 [ms]動くとvruntimeが1.0増えるよう計算 14 0 0 t1 t2 LCPU 1.0 t0

Slide 15

Slide 15 text

currentをランキューに再挿入 15 0 0 t1 t2 LCPU 1.0 t0

Slide 16

Slide 16 text

全タスクのvruntime=1.0になるまで繰り返し 16 1.0 1.0 t0 t1 LCPU 1.0 t2

Slide 17

Slide 17 text

実験プログラム ● 実行方法 ○ ./sched ● 引数の意味 ○ Nproc: 同時実行プロセス(タスク)数 ○ Total: 各プロセスの実行時間 (ms単位) ○ granularity: 測定粒度(ms単位) ● 説明 ○ Nproc個のタスクを同時に動かす ○ 各タスクはtotal[ms]だけ無限ループする。このとき granularity[ms]に一回進捗を記録する ○ 全タスク終了時に、各タスクの ID, 経過時間(us単位), 進捗(%単位)を出力 17

Slide 18

Slide 18 text

実験プログラム実行例 ● 1つのタスクを1000ms実行。1msごとにデータをとる 18 $ ./sched 1 1000 1 0 180 0 ... 0 10613 1 # 1%時点でだいたい1ms … 0 20384 2 # 2%時点でだいたい2ms … 0 979192 100 # 100%時点でだいたい1000ms $

Slide 19

Slide 19 text

パラメタ ● nproc=1, 2, 3 ● total=1000 ● granularity=1 19

Slide 20

Slide 20 text

実験結果(nproc=1) 20

Slide 21

Slide 21 text

実験結果(nproc=2) 21 拡大 3msくらい

Slide 22

Slide 22 text

実験結果(nproc=3) 22 拡大 2msくらい

Slide 23

Slide 23 text

タイムスライスは無限に小さくなるのか? ● 例: レイテンシターゲットが6msでnproc=1000 ○ 各タスクのタイムスライスはたったの 6us？ 23

Slide 24

Slide 24 text

タイムスライスは無限に小さくなるのか? ● 例: レイテンシターゲットが6msでnproc=1000 ○ 各タスクのタイムスライスはたったの 6us？ ● タイムスライスの最低保証値がある ○ 目的: コンテキストスイッチのコストを増やしすぎないようにするため ○ sysctlのkernel.sched_min_granularity_ns 24 $ sysctl kernel.sched_min_granularity_ns kernel.sched_min_granularity_ns = 750000 # 0.75ms $

Slide 25

Slide 25 text

nice値の意味 ● Niceの変化によってタイムスライスの比率が変わる ○ nice値が低い(高優先度): 比率が上がる ○ nice値が低い(低優先度): 比率が下がる 25 T0 0 T1 -1 T0 0 T1 0 T0 0 T1 1 時間 T0 0 T1 0 nice値 T0のnice値 > t1のnice値 T0のnice値 == t1のnice値 T0のnice値 < t1のnice値 T0 0 T1 -1 T0 0 T1 1

Slide 26

Slide 26 text

nice値によるタイムスライスの変化量 ● Nice値が1低いとタイムスライスが1.25倍になる ● nice値を考慮したタイムスライスの計算式 ○ Weight = 1.25 ^ (-nice値) ○ Slice = latency_target * (weight / Σweight) ● 例: 2つのタスクt0, t1がnice値0, -1が存在する ○ T0のweight = 1.25 ^ 0 = 1 ○ T1のweight = 1.25 ^ 1 = 1.25 ○ Σweight = 1 + 1.25 = 2.25 ○ T0のタイムスライス = 6 * 1 / 2.25 ○ T1のタイムスライス = 6 * 1.25 / 2.25 26

Slide 27

Slide 27 text

実験プログラム ● 実行方法 ○ ./sched ● 引数の意味 ○ nvalue: nice値 ○ Total: 各プロセスの実行時間 (ms単位) ○ granularity: 測定粒度(ms単位) ● 説明 ○ 2個のタスクt0, t1を同時に動かす ○ T0のnice値は0, t1のnice値はnvalue ○ 2つのタスクはtotal[us]だけ無限ループする。このとき granularity[ms]に一回進捗を記録する ○ 2つのタスク終了時に、各タスクの ID, 経過時間(us単位), 進捗(%単位)を出力 27

Slide 28

Slide 28 text

実行結果 ● nvalue= 1, total=1000, granularity=1 28

Slide 29

Slide 29 text

もくじ ● スケジューラ ● ロードバランサ ● Fair Share Scheduler ● CFS Bandwidth Controller 29

Slide 30

Slide 30 text

ここから複数LCPUの話 ● LCPUの数を2にする 30 # echo 1 >/sys/devices/system/cpu/cpu8/online # …(*1) # grep -c processor /proc/cpuinfo 2 # *1) LCPU8はLCPU0と一番共有するリソースが少ないので実験が楽。詳細は割愛

Slide 31

Slide 31 text

ロードバランサ ● ランキューはLCPUごとに存在 ● ロードバランサ: 負荷の高いLCPUから負荷の低いLCPUにタスクを移動 ○ 基本: 負荷 == ランキュー長 ○ 正確にはnice値やスケジューリングポリシーを考慮して重み付け (説明は省略) ● 動作契機 ○ 新規タスクの生成時 ○ LCPUがアイドルになった時 ○ スリープしていたタスクの起床時 ○ 所定期間の経過時 31

Slide 32

Slide 32 text

ロードバランサ: 初期状態 ● ランキュー長が偏る 32 LCPU0 LCPU1 ランキュー長=4 忙しいんですけどランキュー長=0

Slide 33

Slide 33 text

バランス後 ● ランキュー長が偏る 33 LCPU0 LCPU1 ランキュー長=2 ありがとうランキュー長=2 しょうがねえなあ移動

Slide 34

Slide 34 text

LCPU数とレイテンシターゲットの関係 ● LCPU数が増えるほどレイテンシターゲットは長くなる ● 計算式 ○ レイテンシターゲット = LCPUが1のときのレイテンシターゲット * (1+floor(lg(LCPU数))) ● 理由 ○ スループット向上のためにレイテンシターゲットは長くしたい ○ しかし応答性向上のためにはレイテンシターゲットを短くしたい ■ 1LCPUに閉じると、スリープ状態から起床したタスクが CPU時間を得るまでの長さはレイテンシターゲットの長さに比例 ○ LCPU数が多ければレイテンシターゲットが長くてもスリープしていたタスクはアイドルな別 LCPU上で起床後即座に実行開始できる可能性が高いはず 34

Slide 35

Slide 35 text

実験 ● LCPU数の増加しながらレイテンシターゲットの値を確認 35 # grep -c processor /proc/cpuinfo 1 # sysctl kernel.sched_latency_ns kernel.sched_latency_ns = 6000000 # echo 1 >/sys/devices/system/cpu/cpu1/online # LCPU数 -> 2 # sysctl kernel.sched_latency_ns kernel.sched_latency_ns = 12000000 # 6000000 * 2 # echo 1 >/sys/devices/system/cpu/cpu2/online # LCPU数 -> 3 # sysctl kernel.sched_latency_ns kernel.sched_latency_ns = 12000000 # 6000000 * 2 # echo 1 >/sys/devices/system/cpu/cpu3/online # LCPU数 -> 4 # sysctl kernel.sched_latency_ns kernel.sched_latency_ns = 18000000 # 6000000 * 3 #

Slide 36

Slide 36 text

実験: schedプログラム再び ● nproc= 2 ● Total = 1000 ● Granularity = 1 36

Slide 37

Slide 37 text

CPU affinity ● タスクを動作させるLCPUの集合を決められる ○ 用途: 全CPUで1つづつ動かしたいハートビート処理 , VMやコンテナが動ける CPUの制限 ○ sched_setaffinity()システムコールやtasksetコマンドによって設定 37 T0 Affinity: 0, 1 T1 Affinity: 0 T2 Affinity: 1 LCPU0 LCPU1 × 移動可〇移動不可

Slide 38

Slide 38 text

実験 ● 2LCPU環境でnproc=2で1coreにbind ○ Taskset --cpu-list 0 ./sched 2 1000 1 38

Slide 39

Slide 39 text

cpuset cgroup ● グループに属するタスクを特定LCPUの集合(cpuset)でしか動作させなくする ○ CPU affinityの発展版 39

Slide 40

Slide 40 text

ロードバランサの階層構造 ● ハードウェア構成によってロードバランサは階層構造を持つ ● 階層の例 ○ NUMAノード間 ○ NUMAノード内のソケット間 ○ ソケット内のコア間 ○ コア内のスレッド間 ● 動作の概略 ○ 最上位階層でバランス -> 1つ下の階層でバランス -> … -> 最下階層でバランス 40

Slide 41

Slide 41 text

ロードバランサの挙動: 初期状態 ● 2ノード×2CPU(合計4LCPU)構成 41 t0 t1 t5 t4 t3 LCPU0 LCPU1 LCPU2 LCPU3 t2 node0 node1

Slide 42

Slide 42 text

一番busyなnodeと暇なnodeを見つける ● 42 t0 t1 t5 t4 t3 LCPU0 LCPU1 LCPU2 LCPU3 t2 node0 node1 タスク数4 タスク数2

Slide 43

Slide 43 text

一番busyなnode内の一番忙しいLCPUを選ぶ ● 43 t0 t1 t5 t4 t3 LCPU0 LCPU1 LCPU2 LCPU3 t2 node0 node1 タスク数3 タスク数1

Slide 44

Slide 44 text

一番暇なnode内の一番暇なLCPUを選ぶ ● 44 t0 t1 t5 t4 t3 LCPU0 LCPU1 LCPU2 LCPU3 t2 node0 node1 タスク数0 タスク数2

Slide 45

Slide 45 text

一番busyなLCPUから一番暇なLCPUにタスクを移動 ● 45 t0 t1 t5 t4 t3 LCPU0 LCPU1 LCPU2 LCPU3 t2 node0 node1 t2 移動

Slide 46

Slide 46 text

古き良きコンシューマ向けCPU ● 1物理CPU, 2コア、2スレッド => 4LCPU 1. 物理CPU内コア間のバランス 2. コア内スレッド間のバランス 46 コア物理CPU コアスレッドスレッド

Slide 47

Slide 47 text

● 1物理CPU, 2CCX(*1), 4コア, 2スレッド => 16LCPU 1. 物理CPU内CCX間のバランス 2. CCX内コア間のバランス 3. コア内スレッド間のバランス CCX 複雑なアーキテクチャ(AMD Ryzen 1800X) 47 *1) L3キャッシュを共有するコアの塊 CCX コアスレッドスレッド CCX コアコアコア物理CPU

Slide 48

Slide 48 text

階層構造の確認方法 ● /proc/schedstat ● 実験環境の場合 48 # cat /proc/schedstat … Cpu0 ... domain0 0003 ... domain1 00ff ... domain2 ffff ... ... cpu2 ... domain0 000c ... domain1 00ff ... domain2 ffff … … # コア内スレッド間のバランス CCX内コア間のバランス物理CPU内CCX間のバランス

Slide 49

Slide 49 text

実験環境におけるCPUの物理構成とLCPU番号 49 LCPU番号 CCX コアスレッド 0 0 0 0 1 1 2 1 2 3 3 4 2 4 5 5 6 3 6 7 7 LCPU番号 CCX コアスレッド 8 1 4 8 9 9 10 5 10 11 11 12 6 12 13 13 14 7 14 15 15

Slide 50

Slide 50 text

ロードバランスの例: 無限ループプログラムの同時実行 ● n=1 50 0 1 0 0 1 2 3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 4 5 6 7 CCX core thread p0

Slide 51

Slide 51 text

ロードバランスの例: 無限ループプログラムの同時実行 ● n=2: 各CCXに均等配置 51 0 1 0 0 1 2 3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 4 5 6 7 CCX core thread p0 p1

Slide 52

Slide 52 text

ロードバランスの例: 無限ループプログラムの同時実行 ● n=8: 各コアに均等配置 52 0 1 0 0 1 2 3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 4 5 6 7 CCX core thread p0 p1 p2 p3 p4 p5 p6 p7

Slide 53

Slide 53 text

ロードバランスの例: 無限ループプログラムの同時実行 ● n=16: 各スレッドに均等配置 53 0 1 0 0 1 2 3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 4 5 6 7 CCX core thread p0 p2 p4 p6 p8 p10 p12 p14 p1 p3 p5 p7 p9 p11 p13 p15

Slide 54

Slide 54 text

おまけ: 変態アーキテクチャ(AMD EPYC7601フル構成) ● 2物理CPU, 4ダイ(*1), 2CCX, 4コア, 2スレッド => 128LCPU 1. 物理CPU間のバランス 2. 物理CPU内ダイ間のバランス 3. ダイ内CCX間のバランス 4. CCX内コア間のバランス 5. コア内スレッド間のバランス 54 *1) CCXを2つ繋いだもの物理CPU 物理CPU ダイダイダイダイ CCX CCX コアコアコアコアスレッドスレッド

Slide 55

Slide 55 text

もくじ ● スケジューラ ● ロードバランサ ● Fair Share Scheduler ● CFS Bandwidth Controller 55

Slide 56

Slide 56 text

1LCPUに戻す ● ここからの話は複数LCPUあると非常ややこしくなるので1LCPUで考える 56 # for ((i=0;i<16;i++)) ; do > echo 0 >/sys/devices/system/cpu/cpu${i}/online > done # grep -c processor /proc/cpuinfo 1 #

Slide 57

Slide 57 text

fair group scheduling ● Cpu cgroup 1. グループ間でCPUを均等配分 2. グループ内でさらに均等配分 ● Cpu cgroupのcpu.sharesパラメタによって重み付け ● ネストも可能 57 Cpu cgroup “Foo” Shaers = 1024 Cpu cgroup “Bar” Shares = 1024 t0 t1 t2 1. Foo, bar間でCPU 時間を均等配分 1. Foo: T0, t1間で均等配分 2. Bar: t2に全部配分

Slide 58

Slide 58 text

LCPU上で動くタスク 58 時間 t0 t1 t2 t0 t1 t2 cgroupなし Cgroupありグループfoo: t0, t1 グループbar: t2 t0 t1 t2 t0 t1 t2 1 1/3 1/3 1/3 1 1/4 1/4 1/2 1/2

Slide 59

Slide 59 text

LCPU上で動くタスク: 重み付けあり 59 時間 t0 t1 t0 t1 Cgroupあり　グループfoo: t0 　　share: 1024 　グループbar: t1 　　share: 1024 Cgroupありグループfoo: t0 Share: 1024 グループbar: t1 Share: 2048 1 1/2 1/2 t0 t1 1 1/3 2/3 t0 t1

Slide 60

Slide 60 text

Usecase: ユーザ間でCPU資源を均等配分 ● 例: ユーザAがt0, ユーザBがt1-t3を動かしているとする 60 Fair share scheduler不使用ユーザごとにcpu cgroup作成時間 T0 (ユーザA) T1 (ユーザB) T2 (ユーザB) T3 (ユーザC) 時間 T0 (ユーザA) T1 (ユーザB) T2 (ユーザB) T3 (ユーザB) タスク同士が公平ユーザ同士は不公平ユーザ同士が公平

Slide 61

Slide 61 text

実験プログラム 1. 2つのcpu cgroup, fooとbarを作る 2. fooにbarの二倍のCPU時間を与える 3. Fooとbar上でそれぞれloopプログラムを動かす 4. topで%cpuを監視 61 # mkdir /sys/fs/cgroup/cpu/foo # mkdir /sys/fs/cgroup/cpu/bar # echo 2048 > /sys/fs/cgroup/cpu/foo/cpu.shares # echo 1024 > /sys/fs/cgroup/cpu/bar/cpu.shares # # ./loop & [1] 25688 # ./loop & [2] 25689 # echo 25688 >/sys/fs/cgroup/cpu/foo/tasks # echo 25689 >/sys/fs/cgroup/cpu/bar/tasks # top -b -d 1 -p 25688 -p 25689

Slide 62

Slide 62 text

実験結果 62 # top -b -d 1 -p 25688 -p 25689 … PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25688 root 20 0 4376 800 736 R 66.0 0.0 1:11.55 loop 25689 root 20 0 4376 744 684 R 33.0 0.0 1:08.45 loop … PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25688 root 20 0 4376 800 736 R 66.3 0.0 1:12.22 loop 25689 root 20 0 4376 744 684 R 32.7 0.0 1:08.78 loop Fooに属するloopプログラムがbarに属するそれの1.5倍CPU時間を得ている時間 Loop (foo) Loop (bar) current Loop (foo) Loop (bar) レイテンシターゲット (lt) lt*(⅔) lt*(⅓)

Slide 63

Slide 63 text

もくじ ● スケジューラ ● ロードバランサ ● Fair Share Scheduler ● CFS Bandwidth Controller 63

Slide 64

Slide 64 text

Fair group schedulingの課題: 上限設定ができない ● 例: 2ユーザA, Bが同居するマルチテナントシステム ○ やりたいこと: 個々のユーザにCPU資源を”最大”1/2与えたい ■ ユーザ間の不平等、過剰なサービスの提供を避けたい ○ Fair group schedulingにできること: ユーザごとにグループ作成 64 時間 Aだけがタスクを動かしている状態 (あるべき姿) Aのタスク Aだけがタスクを動かしている状態 (現実) Aのタスク idle Aのタスク idle

Slide 65

Slide 65 text

CFS bandwidth controller ● あるcpu cgroupが所定期間内に動ける時間を制限 ○ cpu.Cfs_period_us: 期間([us]単位) ○ Cpu.cfs_quota_us: 動ける時間([us]単位) ● ネストも可能 ● 主な用途: VMやコンテナのリソース制限 65 時間 Aのタスク idle Aのタスク idle quota period quota切れ quotaチャージ

Slide 66

Slide 66 text

実験プログラム 1. fooという名前のCpu cgroupを作る 2. Fooに属するタスクはCPU資源の半分しか使えないようにする 3. Loopプログラムをバックグラウンドで動かしてfooに属させる 4. Topで%cpuを監視 66 # Mkdir /sys/fs/cgroup/cpu/foo Echo 100000 > /sys/fs/cgroup/cpu/foo/cpu.cfs_period_us Echo 50000 > /sys/fs/cgroup/cpu/foo/cpu.cfs_quota_us # ./loop & [1] 25676 # echo 25676 > /sys/fs/cgroup/cpu/foo/tasks # Top -b 1 -d 1 -p 25676

Slide 67

Slide 67 text

実験結果 67 # top -b -d 1 -p 25576 ... PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25676 root 20 0 4376 856 796 R 50.0 0.0 2:56.33 loop ... PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25676 root 20 0 4376 856 796 R 51.0 0.0 2:56.84 loop ... LCPU上でこのプロセスしか動いていないのに 50%しかCPU資源を使えていない時間 loop idle current loop idle loop idle quota period loopのquota切れ loopのquotaチャージ

Slide 68

Slide 68 text

おわりに ● より深く知りたければ… ○ 実験プログラムのパラメタを色々変えながら実行 ○ ソースを読む(Linuxカーネルソースのkernel/sched/以下) ○ 実験プログラムを作る ○ Ftraceなどのトレーサを使う ● 漫然とソースを読むより実験しながらのほうが理解しやすいよ！ ○ これはどのソフトウェアでも同じ 68

Slide 69

Slide 69 text

リンク集 ● 実験プログラムのソース ○ https://github.com/satoru-takeuchi/kernelvm_hokuriku_part4 ● 「Linuxのプロセススケジューラの歴史」 ○ https://speakerdeck.com/sat/linux-sched-history ● 「タスクスケジューラ用のsysctlパラメタ」 ○ https://qiita.com/satoru_takeuchi/items/7830f28c88e08ff4c720 69