리눅스 tick관련
글쓴이: choboja / 작성시간: 토, 2010/11/20 - 12:25오전
안녕하세요? 리눅스 커널을 공부하고 있는 학생입니다.
cfs 스케쥴러관련 코드를 공부하고 있는데 hrtimer라는 것이 있군요.
이것으로 인해 실제 4ms(250hz설정시)로 발생되던 time tick 또한 hrtimer를 이용하여 구현되는 걸로 이해했습니다.
즉, 4ms마다 발생되게 hrtimer가 작성되고 그 timer가 깨어나서 4ms마다 발생되는 tick에서 해야되는 일을 수행을 하는 것으로 이해했네요.
이것 덕분에 실제 타스크 또한 이것보다 작은 단위로 스케쥴링이 가능한 것 같구요. 제가 이해한 것이 맞는지요?
하지만 코드에서는 sysctl_sched_min_granularity가 보통 4ms로 되어있네요. 그렇다면 실제 타스크(weight가 낮은 녀석들)들의
최소 실행시간을 4ms로 보장이 된다는 것인가요?
제가 생각했던 것은 4ms보다 짧은 scheduler tick을 받는 녀석은 hrtimer를 이용하여 실제 time tick 보다 적은 시간 수행이 가능한 것으로
이해했습니다.
음.. 아직 정확한 정리가 되지 않네요.
답변 부탁드리겠습니다.
Forums:
;하지만 코드에서는
;하지만 코드에서는 sysctl_sched_min_granularity가 보통 4ms로 되어있네요.
;그렇다면 실제 타스크(weight가 낮은 녀석들)들의
;최소 실행시간을 4ms로 보장이 된다는 것인가요?
네 맞습니다, CFS에서는 구조적으로 런큐에 전체 task가 많으면 많을 수록 무한정으로 할당된 timeslice가 줄어 들게 됩니다.
너무 빈번한 contex switch는 performance를 저해하기 때문에 저러한 설정치를 준것이죠.
;제가 생각했던 것은 4ms보다 짧은 scheduler tick을 받는 녀석은
; hrtimer를 이용하여 실제 time tick 보다 적은 시간 수행이 가능한 것으로 이해했습니다.
근본적으로 sysctl_sched_min_granularity의 의미가 최소한 해당 시간만큼은 실행을 보장하자 입니다.
제가 알기론 아닙니다.
>> 하지만 코드에서는 sysctl_sched_min_granularity가 보통 4ms로 되어있네요.
>> 그렇다면 실제 타스크(weight가 낮은 녀석들)들의
>> 최소 실행시간을 4ms로 보장이 된다는 것인가요?
>
> 네 맞습니다, CFS에서는 구조적으로 런큐에 전체 task가 많으면 많을 수록 무한정으로 할당된 timeslice가 줄어 들게 됩니다.
> 너무 빈번한 contex switch는 performance를 저해하기 때문에 저러한 설정치를 준것이죠.
sysctl_sched_min_granularity 값은 run queue 내의 모든 task들의 weight가 같을 때의 timeslice 값입니다.
좀더 정확히는 __sched_period() 함수에서 모든 task들에게 분배해 줄 전체 (scheduling latency) period 값을 계산할 때에 사용되며
각 task들은 이 period 값을 자신의 weight에 따라 나누어가지기 때문에
sysctl_sched_min_granularity 보다 작은 timeslice를 할당받을 수 있습니다.
참고로 CFS의 기본 period 값은 sysctl_sched_latency로 정해져 있는데
run queue 내의 task가 거의 없는 경우에는 sysctl_sched_min_granularity 보다 큰 timeslice를 할당받지만
반대로 task 수가 많아지는 경우에는 (위에서 말씀하신대로) 아주 작은 timeslice를 할당받을 수 있을 수 있으므로
task 수가 일정한 값 (sched_nr_latency)보다 많아지면 이 값 대신 task 수와 sysctl_sched_min_granularity 값을
이용하여 period 값을 동적으로 계산하도록 되어 있습니다.
쓰신 내용이 오해의 소지가 있네요
>>sysctl_sched_min_granularity 값은 run queue 내의 모든 task들의 weight가 같을 때의 timeslice 값입니다.
sysctl_sched_min_granularity 값은 run queue 내의 모든 task들의 weight가 같을 때 가질 수 있는 '최소' timeslice 값입니다.
>>sysctl_sched_min_granularity 보다 작은 timeslice를 할당받을 수 있습니다.
sysctl_sched_min_granularity 의 기본 개념이 최소한 해당 시간만큼은 실행을 보장하자 입니다.
하지만 정확히는 sched_slice()는 __sched_peiod()의 전체 값을 weight 별로 나눠 받기 때문에
이야기 하신대로 sched_slice()는 sysctl_sched_min_granularity(e.g. 4ms) 보다 작은 값을 가질 수 있습니다.
그러나, 위의 상황 (CONFIG_HZ:250)에서 sysctl_sched_min_granularity(4ms) 이하의 timeslice는 의미가 없습니다.
실제 schedule 여부의 판단은 timer interrupt 발생 시 마다 하게 되며 그 주기가 4ms 입니다.
더 높은 HZ 나 dynamic tick을 사용하게 된다면 의미가 있겠네요.
지적 감사합니다
하지만 HZ가 250인 상황에서도 커널 선점을 고려한다면 4ms 이하의 timeslice가 의미 없지는 않을 것입니다.
task의 선점 포인트가 오직 timer interrupt 만은 아니기 때문에
반드시 최소 4ms 동안 실행된다고 보장할 수는 없지 않을까요?
말씀하신 대로 task의 선점 포인트는 timer
말씀하신 대로 task의 선점 포인트는 timer interrupt만이 아닙니다.
kernel의 실행흐름이 종료되고 복귀할 때( system call, isr ), preempt_schedule 함수 등에서
NEED_RESCHED(schedule이 필요하다는 flag)를 보고 명시적인 schedule()을 호출하게 됩니다.
그러나, CFS에서 time slice를 비교하여 NEED_RESCHED를 설정(check_preempt_tick())하는 시점은
각 timer interrupt가 발생하는 시점입니다.
따라서, 1 tick 이내에 선점 포인트가 있다고 하여도 schedule이 되지는 않습니다.
물론 CFS 외에도 커널 내에서 NEED_RESCHED를 설정하는 부분은 많습니다.
그러나 그런 경우는 주로 특정 시스템 콜에서 설정하는 부분으로 명시적으로 cpu 제어권을 내어 놓겠다는 의도로 봐야 겠지요.
테스크 깨울 때마다 NEED_RESCHED 켜질 수
테스크 깨울 때마다 NEED_RESCHED 켜질 수 있어요. 아니면 선점이 무슨 소용이 있나요.
.
.
댓글 달기