About Process (2) : Process Scheduling

멀티프로그래밍의 목적은 항시 돌아가는 여러개의 프로세스를 가짐으로써, CPU 성능을 최대화 하는데에 목적이 있다고 할 수 있을 것이다. (멀티 코어까지 안가도, 싱글 코어 CPU에서 프로세스 하나가 쭉 파업하느라 다른 프로세스가 일을 못하면 손해 아닐 것인가?) 쨋든 프로세스의 생애 과정을 보면서 이게 어떻게 되는지 보도록 하자.

 

선생은 하나지만 n명의 학생들을 가르칠 수 있는 분신술을 떠올려보자.

 

 

 

Scheduling Queues

 

프로세스가 시스템에서 돌려질 것이라면, 일단은 (통상적으로는) Linked List로 구현된 ready queue에 집어넣어지게 된다.그리고 좀 대기를 타다가 CPU에서 돌게 되는데.. I/O 대기를 타던, 아니면 쫑나던, 특정 이벤트를 기다리던 하는 상황이 올것 아닌가? 이런 얘들은 CPU에서 돌다가 wait queue로 넘어가게 된다.  그리고 뭐 이벤트가 다시 끝나면 레디큐로 넘어가고, Terminate되면 종료되고.. 이런 과정인 셈. (이때 Ready Queue에서 CPU로 넘어가는 것을 Dispatch라고 한다.)

 

쨋든 결론적으로 프로세스는 라이프타임 동안 참으로 다양한 Queue들 사이를 오가게 되는데.. 이때 CPU 스케쥴러는 이 Queue들을 Ready Queue에 집어넣던 아니면 CPU에 돌려서 실제로 실행시키던 하는 역할을 하게 된다. 물론 프로세스가 I/O-bound냐 아니면 CPU-bound냐에 따라서 따질것도 많고.. 나중에는 프로세스를 disk로 유배보내는 Swapping도 하게 되지만...

 

 

 

Context Switch

 

 

여튼 Scheduler는 CPU 코어가 계속 번갈아 가면서 프로세스를 굴리게 하는데... 다만 번갈아 할때는 반드시 프로세스의 Context를 저장하고 다시 불러와야 할 필요가 있다. 앞에서 배운대로라면 프로세스를 다시 배정할때 마다 PCB를 불러와서 지지고 볶아야 하는 셈. 

 

다만 CPU 코어를 다른 프로세스로 바꾸는 작업은 저장 작업과 불러오기 작업을 동시에 요한다. 이러한 과정을 Context Switch라고 하게 된다. 커널은 예전 프로세스의 context를 저장하고 돌릴 새 프로세스의 context를 불러온다. 다만 문제는 context switch를 하는 동안은 CPU를 못굴려 먹는 문제가 발생하며, switching speed는 프로세스 마다 다를 것이며, 당연하게도 하드웨어 빨을 많이 탈것이며, 경우에 따라서는 OS 자체가 Context switching 비용을 많이 잡아먹을 수도 있으며.... 뭐 쨋든 후술하도록 하자.