Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Linuxのプロセススケジューラのしくみ その2 タイムスライスの計算方法
Search
Satoru Takeuchi
PRO
September 27, 2020
Technology
0
1.3k
Linuxのプロセススケジューラのしくみ その2 タイムスライスの計算方法
以下動画のテキストです
https://youtu.be/s7OEjcGHAXQ
Satoru Takeuchi
PRO
September 27, 2020
Tweet
Share
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
APIとABIの違い
sat
PRO
5
51
ファイルシステムへのアクセス方法
sat
PRO
0
21
ファイルシステム
sat
PRO
1
22
低レイヤソフトウェア技術者が YouTuberとして食っていこうとした話
sat
PRO
7
6.1k
ポーリングと割り込み
sat
PRO
1
77
Rook: Intro and Deep Dive With Ceph
sat
PRO
1
140
会社員しながら本を書いてきた知見の共有
sat
PRO
3
870
デバイスにアクセスするデバイスファイル
sat
PRO
1
59
ファイルシステムのデータを ブロックデバイスへの操作で変更
sat
PRO
1
47
Other Decks in Technology
See All in Technology
モダンフロントエンド 開発研修
recruitengineers
PRO
8
5.4k
Jaws-ug名古屋_LT資料_20250829
azoo2024
3
190
AI時代に非連続な成長を実現するエンジニアリング戦略
sansantech
PRO
2
760
生成AI時代のデータ基盤
shibuiwilliam
0
580
「AI2027」を紐解く ― AGI・ASI・シンギュラリティ
masayamoriofficial
0
140
ライブサービスゲームQAのパフォーマンス検証による品質改善の取り組み
gree_tech
PRO
0
170
シークレット管理だけじゃない!HashiCorp Vault でデータ暗号化をしよう / Beyond Secret Management! Let's Encrypt Data with HashiCorp Vault
nnstt1
2
120
Microsoft Fabric のネットワーク保護のアップデートについて
ryomaru0825
1
120
Kiroと学ぶコンテキストエンジニアリング
oikon48
4
660
ZOZOTOWNフロントエンドにおけるディレクトリの分割戦略
zozotech
PRO
18
5.9k
現場が抱える様々な問題は “組織設計上” の問題によって生じていることがある / Team-oriented Organization Design 20250827
mtx2s
7
65k
ヒューリスティック評価を用いたゲームQA実践事例
gree_tech
PRO
0
180
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The Art of Programming - Codeland 2020
erikaheidi
55
13k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Testing 201, or: Great Expectations
jmmastey
45
7.6k
Gamification - CAS2011
davidbonilla
81
5.4k
Balancing Empowerment & Direction
lara
3
600
GraphQLとの向き合い方2022年版
quramy
49
14k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Rails Girls Zürich Keynote
gr2m
95
14k
Transcript
Linuxのプロセススケジューラのしくみ その2: タイムスライスの計算方法 Aug 30th, 2020 Satoru Takeuchi Twitter: satoru_takeuchi,
EnSatoru 1
おさらい • その17 Linuxのプロセススケジューラの仕組み その1 時分割によるスケジューリング ◦ 実行可能プロセス数 nが増えるとタイムスライスが短くなったような …?
2 0 1 0 1 2 0 1 2 3
• タイムスライス=レイテンシターゲット/実行可能プロセス数n ◦ レイテンシターゲットとして決めた時間に一回 CPU時間を得られる タイムスライスの計算方法 3 n=2 n=3 n=4
時間 t0 t1 t0 t1 t0 t1 t2 t0 t1 t2 t0 t1 t2 t3 t0 t1 t2 t3 レイテンシターゲット レイテンシターゲット
レイテンシターゲットの値 • sysctlパラメタによって読み書き可能 ◦ kernel/sched_latency_ns [ナノ秒] • パラメタチューニングの基準 ◦ 応答性能重視(主にデスクトップ環境
): 値を小さくする ◦ スループット重視(主にサーバ環境): 値を大きくする • CPU数が変わると変化する ◦ レイテンシターゲット =1CPUのときのレイテンシターゲット ×(1+log2(ncpus) ▪ CPU数が多いとサーバ用途が多いだろうという推測 ▪ CPU数が多いとプロセス起床時に他の CPU上ですぐ動ける可能性が高い 4
タイムスライスの最低保証値 • 例: レイテンシターゲットが10msでnproc=1000 ◦ 各タスクのタイムスライスはたったの 10us? • タイムスライスの最低保証値がある ◦
目的: コンテキストスイッチのコストを増やしすぎないようにするため ◦ Sysctlのkernel.sched_min_granularity_ns 5
nice値の意味 • niceの変化によってタイムスライスの比率が変わる ◦ nice値が小さい(高優先度): 比率が上がる ◦ nice値が大きい(低優先度): 比率が下がる •
レイテンシターゲットは変わらない 6 p0 p1 p0 p1 p0 p1 時間 p0 p1 p0のnice値 > p1のnice値 p0のnice値 == p1のnice値 p0のnice値 < p1のnice値 p0 p1 p0 p1 レイテンシターゲット レイテンシターゲット
実験 • 目的 ◦ タイムスライスにnice値が与える影響を確認 • 実験プログラムnice.cの概要 1. 1つのCPU上で無限ループするプロセス p0とp1を同時に100ミリ秒間動かす
▪ 第一引数としてp1のnice値を与える: -10 or 0(デフォルト値) or 10 2. 2つのプロセスはCPUを1ミリ秒使うごとに次の情報を記録する ▪ プロセスの番号 ▪ プロセス開始時からの経過時間を記録 3. 100ミリ秒経過後に2つのプロセスの記録を出力 7
結果 8 p0 p1 p0 p1 p0 p1
まとめ • タイムスライスは実行可能プロセス数が増えるほど短くなる ◦ レイテンシターゲットに定めた期間に一回 CPU時間を得られる ◦ コンテキストスイッチコストが高くなりすぎないように最低保証値がある • CPU数が増えるとレイテンシターゲットの値が増える
• nice値による優先度の高低によってタイムスライスの比率が上下する 9