본문 바로가기

CS/오퍼레이팅 시스템

12. 프로세스 스케줄링

 

- 프로세스는 active entity : 여러개의 프로세스가 번갈아 수행되기 때문에 스케줄링이 필요

 

* process scheduling queue

- job queue : 시스템 내의 모든 프로세스의 집합

                      메인 메모리로 로드할 프로세스를 job큐에서 선택

- ready queue : 현재 state가 ready인 프로세스의 집합

                          프로세스가 waiting 상태면 절대 스케줄링을 하지 않음

                          cpu는 ready 큐에서 하나를 선택 = 프로세스 스케줄링

- device queue : 입출력 연산을 기다리는 프로세스들의 집합

=> 프로세스들은 이 큐들을 옮겨다니면서 실행 됨

 

- ready큐에 있는 프로세스 하나를 선택해서 cpu에 dispatch됨

- cpu에서 실행이 끝나면 모두 ready상태가 됨

- 입출력 연산이 필요하면 device큐에 들어가고 나머지는 ready큐에 들어감

- device큐에서 입출력 연산 후 ready큐로 이동

 

* cpu 스케줄링에서 가장 중요한 것

- I/O bound 프로세스 : cpu 연산보다는 io 연산이 많음, cpu 보다는 디스크 ssd 같은 스토리지 많이 사용

- cpu bound 프로세스 : cpu 연산을 많이 사용하고 io 연산 시간을 짧음

- IO 연산은 CPU 연산보다 빠르게 수행되기 때문에 IO 바운드 프로세스에게 우선순위를 더 높게 줌

- cpu 바운드 프로세스에게 우선순위를 높게 주면 긴 연산량이 필요한 cpu 연산을 연산량 적은 io 바운드가 기다리게 됨

   => 수행 시간이 짧은 IO 연산이 오랫동안 기다려서 부작용이 생길 수 있음

- 그래서 두가지로 분류해서 io 바운드 프로세스에 우선순위를 높게 주는 것

 

* 스케줄러

- long term scheduler, short term scheduler, midterm scheduler

 

- long term (job scheduler) :

메모리로 올릴 프로세스를 결정, 어떻게 메모리를 할당할 지가 중요

이 스케줄러의 호출 주기는 매우 김 -> 자주 호출 안된다는 말

멀티프로그래밍의 정도를 결정(메모리 내 프로세스 개수)

메모리에 프로세스가 너무 많으면 프로세스가 죽거나 불안정해질 수 있음

대부분의 os가 long- term 이용 안함

 

- short term (cpu scheduler) :

현재 ready 큐에 있는 프로세스 중 하나를 선택해서 cpu를 할당하는 스케줄러

매우 자주 호출

리눅스에서는 디폴트로 10ms마다 한번씩 호출 -> 매우 빠르게 결정해서 새로운 프로세스에게 cpu할당해야함

 

- medium term : 어떤 프로세스를 swapping 할지 결정

 

* context switch

- 기존에 수행되던 프로세스 A의 context(register)를 그 pc 위에 저장하고

  새로 수행되는 프로세스 B의 pc에 있는 걸 레지스터에 로드 => 오버해드가 굉장히 큼

- 연산이나 io도 아니라서 유용한 일을 하는게 아님 

  오버헤드를 줄이는 게 중요함

 

- SUN UltraSPARC : 레지스터가 많아서 레지스터를 옮기는 걸 줄임

- ARM : multiple store and load 매우빠르게 로드, 스토어

 기존 수행 프로세스의 레지스터 값을 메모리로 저장

 새로 수행할 프로세스 레지스터 값을 해당 디스크 pcb에서 레지스터로 로드

- R0 주소를 읽고 R5~R8에 로드하라는 연산 -> 하나의 instruction으로 레지스터로 로드함

- 여러 레지스터를 읽어야하지만 하나의 instruction으로 생각하고 load&store

- multiple store&load가 제공되지 않으면 각 주소값을 로드할 때마다 별도의 instruction 사용