Process Scheduling

Process Scheduling 21-1기 유준영

1. Process Switch(Dispatch) - Process Switch(프로세스 전환)? CPU상에서 동작하고 있던 프로세스의 실행을 중단하고, 새로운 프로세스를 실행 예> 프로세스 A를 프로세스 B로 바꾸는 작업-> 프로세스 전환(Process Switch) 프로세스 공간 관리(프로세스 공간 관리) 레지스터, 프로그램 카운터(실행중인 명령) 레지스터, 스택 포인터(스택), 각종 연산용 레지스터

2.1 context_switch() – switch_mm() 커널스레드 - mm_struct를 빌려 쓰더라도 커널 공간의 주소 범위를 사용하고 있다) 그래서 TLB를 정리하지 않아도 된다. 일반 프로세스 - 통상 프로세스의 공간을 전환 하는것이기 때문에 TLB가 정리되어야 한다.

paging의 숫자가 커지면, 자신이 원하는 페이지를 찾는데 걸리는 시간이 길어질 것이다. 그게 물론 자주 사용하여 상주하는 페이지라고 하더라도 말이다. 따라서 TLB는 이러한 문제점을 해결하기 위하여, 자주 사용하는 페이지에 대하여 별도의 페이지 테이블을 사용하는 것이다.

2.2 context_switch() – switch_to() 인수 prev는 현재 동작 중인 프로세스의 task_struct구조체 가리키고 있다. 인수 next는 다음에 동작 시킬 프로세스의 task_struct구조체 가리키고 있다. prev로 표시될 프로세스의 ESP 레지스터를 백업 next로 표시될 프로세스의 ESP 레지스터를 설정 prev로 표시될 프로세스의 EIP 레지스터를 백업 next로 표시될 프로세스의 EIP 레지스터를 설정 Next page

2.3 context_switch() – __switch_to() 1. EIP와 ESP 이외의 레지스터를 전환 2. FPU레지스터의 지연 전환 기능 3. GS세그먼트, FS세그먼트 전환 ( save, load ) 4. 디버그 관련 레지스터 전환 linux-2.6.24/arch/x86/kernel/process_32.c __switch_to() - 참고

3. context_switch() Result 2.1. switch_mm() – 프로세스 공간의 전환 처리 2.2. switch_to() – EIP, ESP 레지스터의 전환 처리 2.3 __switch_to() – EIP와 ESP 이외의 레지스터 전환 처리

4. Process Scheduler(1) - schedule() 실행 가능한 프로세스 전체를 감시해서 어느 프로세스에 실행 권한을 줄 것인지는 Process Scheduler라 한다. 스케줄링 방침 응답 성능 VS 처리율 예)쉘 프로그램(대화형 프로세스)-> 응답율 수치 계산 프로그램 -> 처리율 1.대화형 프로세스의 응답 성능 향상 -대화형 프로세스가 동작하면 프로세스를 전환(선점)하여 우선적으로 동작 -단위 시간당 실행 시간이 적은 프로세스를 대화형 프로세스라고 가정

4. Process Scheduler(2) - schedule() 2. 우선순위의 지표 실행 우선순위 고정 우선순위(nice 값)+ 동적 우선순위(시간에 따라) 시간에 따라 -> cpu를 이용한 시간에 따라~ cpu를 보다 많이 사용한 프로세스는 동적 우선순위가 낮다

4. Process Scheduler(2) - schedule() 3. 실행 보증 프로세스 스케줄링은 공평성을 유지하기 위해 실행 가능한 프로세스에 실행 할당 시간( time slice )을 줍니다. 이 실행 할당 시간은 고정 우선순위를 기본으로 계산된다. 고정 우선순위가 높은 프로세스는 실행 시간이 약간 길게 할당되어 다른 프로세스에 비해 실행 권한을 잡을 수 있는 기회가 늘어납니다. 4. 카운터 방식에 의한 처리율의 향상 과거 UNIX방식과 다르게 한 번 실행 권한을 잡은 프로세스는 일정 시간 계속해서 실행을 할 수 있기 때문에 프로세스 재스케줄링 횟수를 최소한 으로 줄일 수 있습니다.

Real Time Process 실시간 프로세스는 일반 프로세스보다 높은 실행 우선순위를 가지며 우선 적으로 스케줄링 된다. 일반 프로세서는 시간을 이용하여 동적 우선순위 내리거나 실행 할당 시간을 줄일 수 있지만 실시간 프로세스는 특별하게 취급되어 마음대로 우선순위를 내리고 올리고 실행 할당 시간도 무제한 이다 멀티프로세서 시스템에서의 프로세스 스케줄링 대칭형 멀티프로세서 시스템에 프로세서의 우선순위가 바뀌더라도 프로 세스를 다른 CPU로 이동하지 못하게 하는 것이 처리 효율을 높일 수 있습 니다. 결론은 특정 CPU에서 한번 실행된 프로세스는 다음에도 같은 CPU에서 실행되어야 합니다. 이유는 해당 프로세스가 이용한 물리 메모리의 내용이 캐시 기억 장치(예를 들면 TLB)에 저장 되기 때문이다.

1. 실행 우선순위별 실행 큐 리눅스커널2.6의실행 큐는 실행할 프로세스의 우선순위 별로 슬롯을 준비하고 있다. -> 이것에 의해 재 스케줄링 시 실행 우선순위가 가장 높은 프로세스를 쉽게 찾을 수 있다. But 실행 가능한 프로세스가 여러 개 존재 하더라도 검색 횟수는 항상 일정하기 때문에 검색지정(오더)1인 스케줄러 즉, O(1) 스케줄러 Active 큐 : 실행 가능한 프로세스 Expired 큐 : 실행 할당 시간을 다 써 버린 프로세스

2. CPU별 실행 큐 멀티프로세서 시스템에서는 실행 큐를 CPU별로 준비 특정 프로세스는 매회 특정CPU상에서 실행 다만, 실행 큐 간의 부하 상태가 한쪽으로 너무 치우치게 되면 실행 대기 프로세스를 이동시켜 밸런스 취함 =>load_balance함수 또한 프로세스를 실행할 때 아이들 상태인 프로세서에 실행 큐간의 실행 대기프로세스를 할당한다. =>try_to_wake_up함수

3. 아이들(idle) & 현재 작업(Current) 프로세스 아이들 프로세스 : 실행 가능한 프로세스가 하나도 존재하지 않을 때 아이들 프로세스를 준비하여 실행 가능한 프로세스가 나타나 선점될 때까지 계속 기다림 (예> 윈도우 system idle process ) 의미: 아이들 프로세스는 현재 사용 중이지 않는 자원을 말한다 리눅스커널2.6에서는 task_struct구조체 내의 일부 멤버와 함께 thread_info구조체로 분할되었다. 그래서 스택 포인터의 하위 비트를마스크해서 프로세스용의 thread_info구조체를 구할수 있게 되고, 그 구조체로부터 task_struct구조체를 구할 수 있다.

4. 프로세스 바인딩 Sched_setaffinity시스템콜을 사용하여 프로세스를 명시적으로 특정 CPU의 실행 큐에서만 동작하게 할 수 있다. Sched_setaffinity시스템 콜의 정보는 task_struct구조체 내에 보존되어 있고, 실행 큐 사이의 부하 밸런스를 조정할 때 고려한다.

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. 타임 슬라이스 어떤 태스크가 선점되기 전까지 실행될 수 있는 시간이 얼마나 남았는지를 가리키는 값 낮은 우선순위 또는 덜 인터랙티브 함 높은 우선순위 또는 매우 인터랙티브 함 기본 100ms 최대 800ms 최소 5ms

4. 실제 상황에서의 스케줄링 정책 2개의 실행 가능한 프로세스 1. 텍스트 에디터 태스크 : I/O 중심의 프로세스 2. 비디오 인코더 태스크 : 프로세서중심의 프로세스 스케줄러는 인터랙티브한 작업을 하는 텍스트 에디터 태스크에게 높은 우선순위와 긴 타임슬라이스 (-19, 800ms) 이로인해 텍스트 에디터는 쓰고 남은 만큼의 타임슬라이스을 갖는다. 텍스트 에디터는 높은 우선순위를 가지므로, 필요에 따라 비디오 인코더를 선점 할 수 있다. 이러므로 텍스트 에디터는 키보드에 즉각 반응할 수 있고, 상대적으로 손해인 것처럼 보이는 비디오 인코더도 남은 시간을 거의 독점함으로 두 응용프로그램의 성능이 최대화 된다.

Linux kernel 스케줄러의 변화(1) • Linux 1.2 -> 라운드 로빈 스케줄링 정책에 따라 작동하는 순환 형 큐를 사용하여 실행 가능한 작업을 관리 ※ 라운드 로빈 정책 -> 공평하게 할당시간을 나눠서 실행하는 것

Linux kernel 스케줄러의 변화(2) • Linux 2.2 -> 스케줄링 클래스라는 개념이 채택되면서 실시간 작업, 우선 순위가 없는 작업 및 비 실시간 작업에 대한 스케줄링 정책을 사용할 수 있다. ※ SMP(Symmetric Multiprocessing) 에대한 지원도 포함

Linux kernel 스케줄러의 변화(3) • Linux 2.4 -> 시간을 에포크(Epoch)단위로 나누며 모든 작업은 해당 시간 조각 동안 실행 할 수 있다. 작업이 해당 시간 조각의 일부를 사용하지 못한 경우에는 다음 에포크에서 더 길게 실행 할 수 있도록 나머지 시간의 절반이 새 시간 조각을 추가 ※ 단점 : 실시간 시스템에 취약하다. 멀티코어 프로세서와 같은 새로운 하드웨어 아키텍쳐도 사용할 수 없다.

Linux kernel 스케줄러의 변화(4) • 초기 Linux 2.6 O(1) 스케줄러 -> O(1) 스케줄러는 실행 가능한 작업을 실행 큐로 추적한다. (실제로는 우선 순위 레벨 별로 두 개의 실행 큐를 사용한다. 하나는 active queue 다른 하나는 expire queue ) active queue에서 next task를 가져오면 된다. O(1) 스케줄러는 확장성이 높지만 상호작용 메트릭과 여러 가지 추론 방법을 통합하여 I/O 또는 프로세서 관련 작업인지 여부를 결정 ※ 단점 : 커널에서 다루기가 쉽지 않고 코드의 양이 매우 많았다.

Linux kernel 스케줄러의 변화(5) • Linux 2.6.21 -> O(1) 스케줄러가 직면하고 있는 문제와 기타 외부 요인으로 인해 변경이 필요 . 이 변경은 RDSL을 이용한 커널 패치가 이루어짐. 그 후Ingo Molnar는 Kolivas의 작업에서 얻은 아이디어로 CFS 개발

5. cd proc/sys/kernel #sysctl -A|grep "sched" |grep -v "domain" kernel.sched_child_runs_first = 0kernel.sched_min_granularity_ns = 3000000kernel.sched_latency_ns = 24000000kernel.sched_wakeup_granularity_ns = 4000000kernel.sched_tunable_scaling = 1kernel.sched_migration_cost = 500000kernel.sched_nr_migrate = 32kernel.sched_time_avg = 1000kernel.sched_shares_window = 10000000kernel.sched_rt_period_us = 1000000kernel.sched_rt_runtime_us = 950000kernel.sched_autogroup_enabled = 1

sched_latency_ns : 선점 지속 기간 ( in nano ) epoch duration (length) in nanoseconds (20 ms by default) 변화(사건)이 지속되는 기간 (20ms) latency 는반응속도 , 즉 nanoseconds 동안 얼마만큼의 시간을 지속되었나? 예> 20ms -> nanoseconds 동안 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 inﬂuences 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 diﬃcult it is for the task to force the preemption. Value가 커질수록 작업의 선점을 하는 일이 더 어려워 진다.

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 schedrt period us period before the are allowed to be executed again

Completely Fair Scheduler for linux 2.6.23 and its tuning • CFS 개요(1) 1. CFS의 기본 개념은 시간을 제공할 때 밸런스(공평성)를 유지하는 것이다. 즉, 프로세스에 공평의 양의 프로세서가 제공되어야 한다. 2. CFS에서는 밸런스를 결정하기 위해 가상 런타임 이라는 지정된 작업에 제공된 시간의 양을 관리한다. 즉, 프로세서에 액세스할 수 있도록 허용된 시간이 작은 작업일수록 더 많은 프로세서 시간이 필요하다.

Completely Fair Scheduler for linux 2.6.23 and its tuning • CFS 개요(2) 3. CFS는 이전 Linux 스케줄러와는 달리 실행 큐에서 작업을 관리하지 않고 시간 순으로 정렬된 red-black 트리를 유지한다. 3.1 스스로 밸런스를 조절한다는 것 즉, 이 트리의 모든 경로는 다른 경로보다 두 배 이상 길러지지 않는다. 3.2 트리에 대한 작업이 O(log n)시간 (n는트리의노드 수) 작업이 빠르고 효율적으로 삽입, 삭제 가능

Completely Fair Scheduler for linux 2.6.23 and its tuning 해당 실행 시간을 가상 런타임에 추가하여 CPU 사용 시간을 계산 한 다음 실행 가능한 경우 트리로 다시 삽임 • Red-black 트리의 예

Completely Fair Scheduler for linux 2.6.23 and its tuning - 시간순으로 정렬된 red-black 트리에 저장되어 있는 작업(sched_entity오브젝트로 표시됨)을 보여 주는 앞 슬라이드 그림을 보면 프로세서에 대한 요구가 높은(가상 런타임이 낮은) 작업부터 차례대로 트리의 왼쪽에 저장되며 프로세서에 대한 요구가 가장 낮은(가상 런타임이 가장 높은) 작업이 트리의 맨 오른쪽에 저장된다. 그런 다음 스케줄러는 공평성을 유지하기 위해 red-black 트리의 맨 왼쪽 노드를 다음에 실행할 노드로 선택한다. 작업은 해당 실행 시간을 가상 런타임에 추가하여 CPU 사용 시간을 계산한 다음 실행 가능한 경우 트리로 다시 삽입된다. 이 방법에 따라 트리의 왼쪽에 있는 작업에 실행 시간이 지정되며 트리의컨텐츠가 오른쪽에서 왼쪽으로 이동하면서 공평성이 유지된다.

Completely Fair Scheduler for linux 2.6.23 and its tuning • CFS 내부 - ./linux/include/linux/sched.h ./kernel/sched.c – cfs_rq구조체 하위참조와 상위노드의 색

Completely Fair Scheduler for linux 2.6.23 and its tuning • 우선 순위와 CFS CFS에서는 우선 순위를 직접 사용하지 않는 대신 작업에 허용된 실행 시간에 대한 지연 인수로 사용한다. 우선 순위가 낮을수록 지연 인수가 높은 작업이며, 우선 순위가 높을수록 지연 인수가 낮은 작업이다. 이는 우선 순위가 높은 작업보다 우선 순위가 낮은 작업에서 작업에 허용된 실행 시간이 더 빨리 소진된다는 것을 의미한다. 이 방법은 우선 순위별로 실행 큐를 관리하지 않아도 되는 효과적인 방법이다.

Completely Fair Scheduler for linux 2.6.23 and its tuning • CFS 그룹 스케줄링 그룹 스케줄링은 스케줄링의 공평성을 높일 수 있는 또 다른 방법으로, 특히 그 안에서 다른 많은 작업이 발생하는 작업의 경우 효과가 높다. HTTP 서버의 전형적인 아키텍처와 같이 들어오는 연결을 병렬 처리하기 위해 많은 작업이 발생하는 서버를 가정해 보자. CFS에서는 모든 작업을 균등하게 처리하는 대신 이 동작을 처리하기 위해 그룹을 사용한다. 작업이 발생하는 서버 프로세스는 계층 구조로 되어 있는 전체 그룹에 대한 가상 런타임을 공유하는 반면 단일 작업은 고유한 독립 가상 런타임을 관리한다. 이 방법에서는 단일 작업이 그룹과 거의 비슷한 스케줄링 시간을 받는다. /proc인터페이스는 프로세스 계층 구조를 관리하는 데 사용되며, 그룹을 형성하는 방법에 대한 전체 제어를 제공한다. 이 구성을 사용하면 사용자, 프로세스 또는 각 변형 전체에 대한 스케줄을 공평하게 할당할 수 있다.

Completely Fair Scheduler for linux 2.6.23 and its tuning • load_weight구조체 weight는 load 즉, 우선순위에 대한 가중치이고 inv_weight는 이의 역수(1/weight)이다. weight값은 nice값을 통해 지정할 수 있는 우선순위에 대응하는 값이다. nice level 0 -> weight = l024 , inv_weight = 1/1024( 계산을 간편하게 하기 위한 목적) nice값의 1 차이는 weight 값의 1.25배 차이이며 이는 프로세스가 CPU를 사용하는 시간에 10% 정도 영향을 준다.

Completely Fair Scheduler for linux 2.6.23 and its tuning • Vruntime원리 delta_exec =>계산하고자 하는 기준값 weight =>자신이 차지하는 가중치 lw =>전체에 대한 가중치

Completely Fair Scheduler for linux 2.6.23 and its tuning

Completely Fair Scheduler for linux 2.6.23 and its tuning 결론 : Nice값이 낮은 프로세스가 weight가 크다

Completely Fair Scheduler for linux 2.6.23 and its tuning CFS는 우선순위에 따라 프로세스를 run queue (red-black tree)에 배치하기 위해 가상의 시간인 vruntime을 사용하는데 이는 실제로 프로세스가 실행한 시간에 nice 0에 대한 현재 프로세스의 우선순위 가중치를 역으로계산한 값이다.(아래의 calc_delta_mine() 호출 시 lw값이 전달되는 위치에 주목하자.)

Completely Fair Scheduler for linux 2.6.23 and its tuning vruntime은 (절대적인) nice 우선순위에 영향을 받기 때문에 우선순위가 낮은 프로세스인 경우 vruntime은 실제보다 더 큰 값을 갖게 되고,우선순위가 높은 프로세스의 경우 반대로 더 작은 값을 갖게 되어 평준화를 이루게 된다.CFS의 run queue (cfs_rq)는 기준이 되는 최소 vruntime값을 유지하며 각 프로세스의 vruntime값과 이 값의 차이를 key로 하여 red-black tree를 구성한다.

Completely Fair Scheduler for linux 2.6.23 and its tuning • Time slice 구하는 방법?

Completely Fair Scheduler for linux 2.6.23 and its tuning • RB트리의 원리

Completely Fair Scheduler for linux 2.6.23 and its tuning • 일반트리VS Avl트리 VS RB트리

Next…. • CFS 에 도입된 스케줄링 클래스 개념 • 최종 정리 – O(1) 스케줄러(2.6 초기) 문제점과 CFS 스케줄러 • Tuning

Process Scheduling