Transcript 어느 프로세스에 실행 권한을 줄 것인지는

프로세스 스케줄링
21-1기 유준영
1. 프로세스 전환 or 프로세스 디스패치
- 프로세스 전환?
프로세스 스케줄러는 가장 동작시키기
좋은 최적의 프로세스에 CPU권한을 준다.
이 처리를 프로세스 전환이 한다.
(Process Switch or Process Dispatcher)
프로세스 공간 관리 레지스터, 프로그램 카운터,
스택 포인터, 각종 연산용 레지스터 바꾸는 기능
2. context_switch() (1)
커널 스레드
mm-> 항상 NULL
active_mm->빌려서 사용하고
있는 mm_struct(실행중에만
의미를 가짐)
일반 프로세스
3. context_switch() (2)
1.1. switch_mm() – 프로세스 공간의 전환 처리
1.2. switch_to() – 각종 레지스터의 전환 처리
1.3 __switch_to() – EIP와 ESP 이외의 레지스터 전환 처리
4. 프로세스 스케쥴러(1) - schedule()
프로세스 디스패처는 지정된 프로세스에 실행 권한을 준다.
그러나 어느 프로세스에 실행 권한을 줄 것인지는 판단은 안 한다.
실행 가능한 프로세스 전체를 감시해서 어느 프로세스에 실행 권한을
줄 것인지는 프로세스 스케줄러가 한다.
스케쥴링 방침
응답 성능 VS 처리율
예) 쉘 프로그램(대화형 프로세스) -> 응답율
수치 계산 프로그램 -> 처리율
보통 nice 값은 대화형 프로세스가 높다
실행 우선순위
고정 우선순위(nice 값) + 동적 우선순위(시간에 따라)
시간에 따라 -> cpu를 이용한 시간에 따라~
cpu를 보다 많이 사용한 프로세스는 동적 우선순위가 낮다
4. 프로세스 스케쥴러(2) - schedule()
실행 보증
프로세스 스케줄링은 공평성을 유지하기 위해 실행 가능한 프로세스에
실행 할당 시간( time slice )을 줍니다.
이 실행 할당 시간은 고정 우선순위를 기본으로 계산된다.
Real Time Process
실시간 프로세스는 일반 프로세스보다 높은 실행 우선순위를 가지며 우선
적으로 스켸줄링 된다. 일반 프로스세은 시간을 이용하여 동적 우선순위를
내리거나 실행 할당 시간을 줄일 수 있지만 실시간 프로세스는 특별하게
취급되어 마음대로 우선순위를 내리고 올리고 실행 할당 시간도 무제한
이다
1. 실행 우선순위별 실행 큐
리눅스 커널 2.6의 실행
큐는 실행할 프로세스의
우선순위 별로 슬롯을
준비하고 있다.
-> 이것에 의해 재 스케줄링
시 실행 우선순위가 가장
높은 프로세스를 쉽게 찾을
수 있다.
Active 큐 : 실행 가능한 프로세스
Expired 큐 : 실행 할당 시간을 다 써 버린
프로세스
But 실행 가능한 프로세스가
여러 개 존재 하더라도 검색
횟수는 항상 일정하기
때문에 검색지정(오더)1인
스케줄러 즉, O(1) 스케줄러
7
2. CPU별 실행 큐
멀티프로세서
시스템에서는 실행
큐를 CPU별로 준비
다만, 실행 큐 간의
부하 상태가 한쪽으로
너무 치우치게 되면
실행 대기 프로세스를
이동시켜 밸런스 취함
-> load_balance함수
8
3. 아이들(idle) & 현재 작업(Current) 프로세스
아이들 프로세스 : 실행 가능한 프로세스가 하나도 존재하지
않을 때 아이들 프로세스를 준비하여 실행 가능한
프로세스가 나타나 선점될 때까지 계속 기다림
리눅스 커널 2.6에서는 task_struct
구조체 내의 일부 멤버와 함께
thread_info구조체로 분할되었다.
그래서 스택 포인터의 하위
비트를 마스크해서 프로세스용의
thread_info 구조체를 구할수 있게
되고, 그 구조체로부터 task_struct
구조체를 구할 수 있다.
9
4. 프로세스 바인딩
Sched_setaffinity 시스템 콜을 사용하여 프로세스를 명시적으로 특정
CPU의 실행 큐에서만 동작하게 할 수 있다.
Sched_setaffinity 시스템 콜의 정보는 task_struct 구조체 내에 보존되어
있고, 실행 큐 사이의 부하 밸런스를 조정할 때 고려한다.
10
1. I/O 중심 VS 프로세서 중심 프로세스
I/O 중심의 프로세스 : 시간의 대부분을 I/O 요청을 보내고 기다리는데
사용
결국, 프로세스들은 짧은 기간동안만 실행가능하게 됨
이유? 다른 I/O 요청에 의해 결국 또 다시 대기 상태(프로세스의 상태중
하나)로 되기 때문
I/O 요청이란? 디스크 I/O뿐만 아니라 키보드 활동 같은 다른 I/O 포함
프로세서 중심의 프로세스 : 시간의 대부분을 코드를 실행하는데
보낸다.
결국, 다른 프로세스가 선점되기까지 계속 실행이 된다.
이유? I/O 요청에 의해 중단 되지 않기때문
1. I/O 중심 VS 프로세서 중심 프로세스
I/O중심의 프로세스를 선호하는 정책은 프로세스 응답 시간을 향상
시킨다.
이유 ? 인터렉티브한 프로세스들은 I/O중심이기 때문이다.
반대로, 프로세서 중심의 프로세스를 선호하는 정책은 프로세스
처리량을 향상 시킨다.
이유? 시간의 대부분을 코드를 실행하는데 보내기때문에
결국, 스케줄러 정책은 대립되는 두가지 목표를 가지고
있다.
1. 프로세스 응답 시간 2. 프로세스 처리량
리눅스 스케줄러는 I/O중심프로세스를 선호하면서
프로세서중심 프로세스를 무시하지 않는 방식으로
설계되어있다.
2. 프로세스 우선 순위
두가지 우선순위
1. nice값에 따른 우선순위
큰 nice값은 낮은 우선순위를 말하고, 낮은 nice값은
높은 우선순위를 말한다.
nice값으로 만들어진 40개 프로세스 (-20~19)는 액티브큐의 어느 슬롯에 지정되는가? -20의
프로세스는 가장 높은 우선순위를 가지고 19가 가장 낮은 우선순위를 가지기때문에 슬롯에 20부터 19까지 순서대로 저장되어있다.
여기서도 중요한 포인트 active 큐에는 실행가능한 프로세스이면서 실행 할당 시간을 가지고 있는
프로세스가 있다.
즉, 우선순위로 실행 할당시간이 주어지기 때문에 그 할당시간이 끝나면 expired 큐로 이동하고
이동 후에 active 큐에 있는 프로세스가 다 실행되면 두개의 큐가 교환하여 처리를 계속한다.
2. 실시간 우선순위
SCHED_OTHER, SCHED_IDLE, SCHED_BATCH 스케줄링 정책에
속하는 일반 태스크는 스케줄링 우선순위가 항상 0 , SCHED_FIFO,
SCHED_RR등과 같은 실시간 스케줄링 정책에 속하는 태스크는 가장 낮은
1~ 높은 99까지의 우선순위가 부여된다.
3. 타임 슬라이스
어떤 태스크가 선점되기 전까지 실행될 수 있는
시간이 얼마나 남았는지를 가리키는 값
낮은 우선순위 또는
덜 인터랙티브 함
최소
5ms
높은 우선순위 또는
매우 인터랙티브 함
기본
100ms
최대
800ms
4. 실제 상황에서의 스케줄링 정책
2개의 실행 가능한 프로세스
1. 텍스트 에디터 태스크 : I/O 중심의 프로세스
2. 비디오 인코더 태스크 : 프로세서중심의 프로세스
스케줄러는 인터랙티브한 작업을 하는 텍스트 에디터
태스크에게 높은 우선순위와 긴 타임슬라이스 (-19, 800ms)
이로인해 텍스트 에디터는 쓰고 남은 만큼의
타임슬라이스을 갖는다. 텍스트 에디터는 높은 우선순위를
가지므로, 필요에 따라 비디오 인코더를 선점 할 수 있다.
이러므로 텍스트 에디터는 키보드에 즉각 반응할 수 있고,
상대적으로 손해인 것처럼 보이는 비디오 인코더도 남은
시간을 거의 독점함으로 두 응용프로그램의 성능이 최대화
된다.
5. cd proc/sys/kernel
#sysctl -A|grep "sched" |grep -v "domain"
kernel.sched_child_runs_first = 0
kernel.sched_min_granularity_ns = 3000000
kernel.sched_latency_ns = 24000000
kernel.sched_wakeup_granularity_ns = 4000000
kernel.sched_tunable_scaling = 1
kernel.sched_migration_cost = 500000
kernel.sched_nr_migrate = 32
kernel.sched_time_avg = 1000
kernel.sched_shares_window = 10000000
kernel.sched_rt_period_us = 1000000
kernel.sched_rt_runtime_us = 950000
kernel.sched_autogroup_enabled = 1
sched_latency_ns : 선점 지속 기간 ( in nano )
epoch duration (length) in nanoseconds (20 ms by default)
변화(사건)이 지속되는 기간 (20ms)
sched_min_granularity_ns : CPU에 밀접한 태스크를 위한 최소
선점 정밀도
granularity of the epoch in nanoseconds (4 ms by default) : the
epoch length is always equal to the multiplicity of the value of
this parameter
nr_running > sched_latency_ns / sched_min_granularity_ns
nr_running : the number of tasks in the queue ( larger then five
by default )
sched_child_runs_first : 기본값은 1로 fork 후에 자식을 먼저
스케쥴한다. 만약 이 값이 0이면 부모에게 바통을 넘긴다.
this parameter influences the order of execution of the parent
process and its child. If it is equal to one (the default value),
then the child process will get CPU prior to its parent. If the
parameter is zero – the reverse will happen.
sched_wakeup_granularity_ns : SCHED_OTHER를 위한
깨우기 정밀도
this parameter describes the ability of tasks being
waken up to preempt the current task (5 ms by default).
The larger the value the more difficult it is for the task to force
the preemption.
sched_migration_cost : this parameter is used by the scheduler to
determine whether the procedure to select the next task should be
called when a task is being waken up.
이 매개변수는 태스크가 깨워졌을때 다음 태스크를 선택한
프로시저가 호출할지 여부를 결정하기 위한 스케줄러에 의해
사용된다.
If the mean real runtime for the current task and the one being
waken up are smaller than this parameter (0.5 ms by default), the
scheduler chooses another task.
To make this work the WAKEUP OVERLAP feature must be active.
the cost of task migration among CPUs (0.5 ms by default) which is
used to estimate whether the code of a task is still present in a CPU
cache.
If the real runtime of the task is smaller than the values of this
parameter then the scheduler assumes that it is still in the cache and
tries to avoid moving the task to another CPU during the load
balancing procedure.
sched nr migrate – the maximum number of task the scheduler
handles during the load balancing procedure (32 by default)
during the load balancing procedure 스케줄러 작업 핸들의 최대
개수 (기본적으로 32)
sched_rt_period_us : – the CFS scheduler waits this amount of time
(0.95 s by default) before scheduling any of the real-time tasks again
sched_rt_runtime_us : the maximum CPU time that can be used by
all the real-time tasks (1 s by default). When this amount of time is
used up these tasks must wait for sched rt period us period before
the are allowed to be executed again