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.2k
Linuxのプロセススケジューラのしくみ その2 タイムスライスの計算方法
以下動画のテキストです
https://youtu.be/s7OEjcGHAXQ
Satoru Takeuchi
PRO
September 27, 2020
Tweet
Share
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
Rook: Intro and Deep Dive With Ceph
sat
PRO
1
110
会社員しながら本を書いてきた知見の共有
sat
PRO
3
790
デバイスにアクセスするデバイスファイル
sat
PRO
1
37
ファイルシステムのデータを ブロックデバイスへの操作で変更
sat
PRO
1
31
デバイスドライバ
sat
PRO
0
49
マルチスレッドの実現方法 ~カーネルスレッドとユーザスレッド~
sat
PRO
2
120
共有メモリ
sat
PRO
3
70
マルチスレッドプログラム
sat
PRO
3
58
Linuxのブートプロセス initramfs編
sat
PRO
2
87
Other Decks in Technology
See All in Technology
AIとともに進化するエンジニアリング / Engineering-Evolving-with-AI_final.pdf
lycorptech_jp
PRO
0
160
MUITにおける開発プロセスモダナイズの取り組みと開発生産性可視化の取り組みについて / Modernize the Development Process and Visualize Development Productivity at MUIT
muit
1
15k
KiCadでPad on Viaの基板作ってみた
iotengineer22
0
290
Glacierだからってコストあきらめてない? / JAWS Meet Glacier Cost
taishin
1
150
Core Audio tapを使ったリアルタイム音声処理のお話
yuta0306
0
180
KubeCon + CloudNativeCon Japan 2025 Recap Opening & Choose Your Own Adventureシリーズまとめ
mmmatsuda
0
260
Understanding_Thread_Tuning_for_Inference_Servers_of_Deep_Models.pdf
lycorptech_jp
PRO
0
180
Connect 100+を支える技術
kanyamaguc
0
190
AWS Organizations 新機能!マルチパーティ承認の紹介
yhana
1
270
Model Mondays S2E03: SLMs & Reasoning
nitya
0
350
ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025
visional_engineering_and_design
3
6.8k
なぜ私はいま、ここにいるのか? #もがく中堅デザイナー #プロダクトデザイナー
bengo4com
0
1.3k
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
810
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
960
GraphQLとの向き合い方2022年版
quramy
49
14k
Automating Front-end Workflow
addyosmani
1370
200k
Embracing the Ebb and Flow
colly
86
4.7k
Code Reviewing Like a Champion
maltzj
524
40k
Making Projects Easy
brettharned
116
6.3k
Unsuck your backbone
ammeep
671
58k
Documentation Writing (for coders)
carmenintech
72
4.9k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
A better future with KSS
kneath
239
17k
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