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
760
Linuxのプロセススケジューラのしくみ その2 タイムスライスの計算方法
以下動画のテキストです
https://youtu.be/s7OEjcGHAXQ
Satoru Takeuchi
PRO
September 27, 2020
Tweet
Share
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
KubeConにproposalを送りたい人へのアドバイス
sat
PRO
3
240
俺とキャンプ2
sat
PRO
1
97
俺とキャンプ3
sat
PRO
0
83
データ冗長化のしくみRAID 基礎概念とRAID1編
sat
PRO
2
27
RAIDの実現方法
sat
PRO
2
57
Linux環境のCPU上で10ミリ秒間に起こること
sat
PRO
3
110
HDDへのアクセス速度は位置によって変わる!??
sat
PRO
4
54
ボリュームマネージャLVM
sat
PRO
2
87
Best Practices of Production-Grade Rook/Ceph Cluster
sat
PRO
1
1.9k
Other Decks in Technology
See All in Technology
開発生産性大幅アップ!Postman VS Code拡張機能
nagix
2
370
チームでロジカルシンキングに改めて向き合っている話 〜学習環境と実践⽅法〜
sansantech
PRO
2
2.1k
ユーザーストーリーのレビューを自動化したみたの
bun913
1
420
反実仮想機械学習とは何か
usaito
PRO
11
4.2k
Google Cloud の AI を支える裏側のインフラを垣間見る!
maroon1st
0
340
プロデザ! BY リクルート vol.18_リクルートのリサーチ実践組織「リサーチブーストコミュニティ」
recruitengineers
PRO
3
280
Azureの基本的な権限管理の勉強会
yhana
0
140
Tellus の衛星データを見てみよう #mf_fukuoka
kongmingstrap
0
180
Meta Quest 3 で動く桜マシマシ WebXR アプリを IBM Cloud Code Engine と Babylon.js で作った話
1ftseabass
PRO
0
120
Databricks における 『MLOps』
databricksjapan
2
170
Azure犬駆動開発の記録/GlobalAzureFukuoka2024_20240420
nina01
1
210
[新卒向け研修資料] テスト文字列に「うんこ」と入れるな(2024年版)
infiniteloop_inc
3
12k
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
73
8.2k
Writing Fast Ruby
sferik
621
60k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
No one is an island. Learnings from fostering a developers community.
thoeni
16
2.1k
Building an army of robots
kneath
300
41k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
14
1.6k
Creatively Recalculating Your Daily Design Routine
revolveconf
210
11k
In The Pink: A Labor of Love
frogandcode
138
21k
A designer walks into a library…
pauljervisheath
200
23k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
78
42k
Agile that works and the tools we love
rasmusluckow
325
20k
Unsuck your backbone
ammeep
663
57k
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