CFS
기본개념
- n개의 Process에게 각각 1/n의 Process time 제공
- 특정 시간안에 n개의 프로세스가 모두 동일한 시간동안 실행
앞선 문제의 대안
- 순차적으로 일정시간 수행하고, 가장 실행이 덜 된 프로세스를 다음 대상으로 스케줄
- nice는 time slice 대신 processor time 비율의 가중치 계산에 사용
- time slice: (자신의 가중치/가중치 총합)으로 계산
targeted latency
CFS가 설정한 가장 작은 스케줄 단위 또는 response time의 최대치 (wait 후 얼마나 기달?)
ex) target latency가 20ms 이면
- 2개의 작업이 있으면 : 각각 10ms 씩 수행
- 20개의 작업이 있으면 : 각각 1ms 씩 수행
minimum granularity
Context switch cost를 감당 할 수있는 최소한의 time slice
- default: 1ms
- target latency가 20인데, 30개의 Task들을 Schedule 한다면?
=> minimum이 1ms 이므로 targeted latency는 30ms로 증가한다.
timeslice = Period * Weight / ΣWeight(i)
Weight(nice) = 1024 / 1.25^nice
ex) taget latency가 20ms 라고 가정한다.
Process |
Nice |
Ratio |
Time Slice |
P1 |
0 |
75.3% = 1024 /(330+1024) |
15.1ms |
P2 |
5 |
24.6% = 335/(335+1024) |
4.9ms |
Process |
Nice |
Ratio |
Time Slice |
P1 |
10 |
75.3% = 110 /(110+36) |
15.1ms |
P2 |
15 |
24.6% = 36/(110+36) |
4.9ms |
Vruntime 이란?
vruntime: 가상 수행 시간
Task가 I/O를 기다리기 위해서 CPU에서 나오거나 time slice를 모두 소모해서 CPU에서 추출되면 변경된
Vruntime을 가지게 된다.
Vruntime: Task(i)가 runtime(i) 만큼 CPU를 점유했다고 가정하면
Vruntime[i]: Vruntime[i] + [ runtime[i] * weight[0] / weight[i] ]
어떤 느낌인가 하면?
Process1에서 exetime이 15.1만큼 실행되었지만 Vruntime 은 20ms
Process2에서 exetime이 4.9만큼 실행되었지만 Vruntime 은 20ms
why? 커널 입장에서는 할당된 time slice 만큼 돌았으니 공평하게 봐야 하므로
(READY Queue 에서는 Vruntime을 가지고 우선순위를 정한다.)
계산예제
Process |
Nice |
Weight |
Time Slice |
CPU Burst |
Vruntime |
P1 |
0 |
1024 |
13 = [ 20 * 1024/ 1574] |
7 |
0 |
P2 |
5 |
335 |
4 = [ 20 * 335/ 1574] |
3 |
0 |
P3 |
7 |
215 |
2 = [ 20 * 215/ 1574] |
2 |
0 |
Vruntime[1] = 0 + [7 * 1024 / 1024] = 7
Vruntime[2] = 0 + [3 * 1024 / 335] = 9
Vruntime[3] = 0 + [2 * 1024 / 215] = 9
Gantte Chart
'Linux > RaspberryPi' 카테고리의 다른 글
Raspberry PI에 Vim 테마 설치 (0) | 2021.06.01 |
---|---|
Raspberry Pi Compute Module 3 b+ EMMC OS 올리기 (0) | 2021.06.01 |
리눅스 및 커널 프로그래밍 스터디 정리 #4 (0) | 2021.01.15 |
리눅스 및 커널 프로그래밍 스터디 정리 #3 (0) | 2021.01.13 |
리눅스 및 커널 프로그래밍 스터디 정리 #2 (0) | 2021.01.12 |