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.1k
Linuxのプロセススケジューラのしくみ その2 タイムスライスの計算方法
以下動画のテキストです
https://youtu.be/s7OEjcGHAXQ
Satoru Takeuchi
PRO
September 27, 2020
Tweet
Share
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
プロセスの生成 exec編
sat
PRO
1
27
プロセスの生成 fork&exec編
sat
PRO
0
19
プロセスの生成 コピーオンライトを使ったfork編
sat
PRO
0
22
プロセスの生成 fork編
sat
PRO
0
25
静的ライブラリと 共有ライブラリの違いを実験で確認
sat
PRO
1
35
ハイテク休憩
sat
PRO
2
190
利きプロセススケジューラ
sat
PRO
5
3.2k
俺とVSCode Python Debugger Extension
sat
PRO
1
200
コード再利用のしくみ ライブラリ
sat
PRO
3
77
Other Decks in Technology
See All in Technology
マイクロサービスにおける容易なトランザクション管理に向けて
scalar
0
220
rootful・rootless・privilegedコンテナの違い/rootful_rootless_privileged_container_difference
moz_sec_
0
100
20241218_今年はSLI/SLOの導入を頑張ってました!
zepprix
0
250
AIエージェントに脈アリかどうかを分析させてみた
sonoda_mj
2
130
株式会社ログラス − エンジニア向け会社説明資料 / Loglass Comapany Deck for Engineer
loglass2019
3
33k
20240522 - 躍遷創作理念 @ PicCollage Workshop
dpys
0
290
MasterMemory v3 最速確認会
yucchiy
0
290
アジャイルチームが変化し続けるための組織文化とマネジメント・アプローチ / Agile management that enables ever-changing teams
kakehashi
2
1.2k
メンタル面でもつよつよエンジニアになる/登壇資料(井田 献一朗)
hacobu
0
170
Fabric 移行時の躓きポイントと対応策
ohata_ds
1
110
.NET 9 のパフォーマンス改善
nenonaninu
0
2.1k
非機能品質を作り込むための実践アーキテクチャ
knih
6
1.8k
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
28
8.3k
The Pragmatic Product Professional
lauravandoore
32
6.3k
GitHub's CSS Performance
jonrohan
1030
460k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
We Have a Design System, Now What?
morganepeng
51
7.3k
Code Review Best Practice
trishagee
65
17k
GraphQLとの向き合い方2022年版
quramy
44
13k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
111
50k
Typedesign – Prime Four
hannesfritz
40
2.5k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
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