본문 바로가기

Linux/RaspberryPi

리눅스 및 커널 프로그래밍 스터디 정리 #5

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