출처 서울대학교 홍성수 교수님, [K-MOOC] 운영체제의 기초, 5주차 CPU Scheduling
선점 리소스와 비선점 리소스
리소스란?
프로세스들이 사용하고 조작하는 대상이다.
<예시> 하드웨어 자원 (CPU 시간, 디스크 공간, 네트워크 채널, IO 디바이스 등) 또는 메인 메모리에 있는 자료 구조.
선점 스케줄링
선점 스케줄링은 OS가 프로세스에게서 CPU를 빼앗아와도 수행에 영향이 없어야 한다. 프로세스가 수행 중에 언제든지 OS가 간섭을 해서 CPU를 빼앗아 올 수 있다.
비선점 스케줄링
프로세스가 스스로 수행을 완료해서 CPU를 내놓았을 때 비로소 다르 프로세스에게 CPU를 전달할 수 있다.
선점 리소스
어떤 프로세스가 리소스를 장악하고 있을 때 운영체제가 리소스를 빼앗아도 문제가 없다.
사실 선점 리소스는 선점적으로 운영할 수도 있고 비선점적으로 운영할 수도 있다. <비유> 유리잔은 부서지는 물체인가
비선점 리소스
어떤 프로세스가 리소스를 장악하고 있을 때 운영체제가 리소스를 빼앗으면 문제가 발생한다.
리소스 매니저로서 OS
OS는 코디네이터의 역할을 한다.
1. 어떤 프로세스에게 리소스를 할당할 것인가.
2. 어떤 프로세스에게 자원을 할당해줄 때 어느 기간 동안 사용하게 할 것인가.
스케줄링의 대상인 CPU Burst 타임
스케줄링의 대상은 프로세스이고, 스케줄링을 해주는 자원은 CPU이다.
그런데 프로세스가 스케줄러를 통해 얻어오는 것은 CPU이기도 하지만 엄밀히 말하면 CPU 를 얼마나 오랜 시간 차지할 것인지이다.
<비유> 심슨 가족(프로세스)이 저녁식사를 하려고 피자를 받았다. 의자는 하나다.(CPU)
첫 번째로는 4명의 가족 구성원 중 누구를 의자에 앉힐지 결정한다.
그다음에 의자에 앉은 사람이 피자 (CPU time)를 얼마나 먹을 것인가를 결정한다.
Time Sharing OS의 스케줄링 대상인 프로세스와 Batch OS의 스케줄링 대상인 JOB
초창기 Batch OS의 스케줄링 대상 entity인 job과 Time sharing OS의 스케줄링 entity인 프로세스를 구별할 필요가 있다.
Time Sharing OS의 스케줄링
프로세스는 생성이 되면 ready queue에 들어간다. 그러다가 CPU를 할당받으면 Running state가 된다. 프로세스가 Running state에 있는 동안 인스트럭션들을 수행한다. 그러다가 blocking system call을 호출하거나 I/O 이벤트 등을 기다리게 되면 그 프로세스는 Waiting state로 간다. Waiting 상태에 한동안 있다가 다시 Ready state로 가게 된다. 이것이 프로세스의 라이프 사이클이다.
프로세스가 Ready 상태에서 보내는 시간, Running 상태에서 보내는 시간, Waiting 상태에서 보내는 시간이 있다.
Preemption 타임
프로세스가 Ready 상태에서 보내는 시간을 Preemption 타임이라고 한다. 내가 CPU를 할당받지 못했기 때문에 ready queue에서 대기하는 것이다.
Running 타임
프로세스가 Running 상태에서 보내는 시간은 Running 타임이라고 한다. 이를 CPU execution 타임이라고 한다.
I/O Waiting 타임
프로세스가 Waiting 상태에서 보내는 시간은 I/O Waiting 타임이라고 한다.
프로세스의 execution이란 Preemption 딜레이, Execution 타임 그리고 I/O Waiting 타임을 계속 반복하는 것이다.
스케줄링의 대상은 CPU Execution Time의 조각이다. OS가 스케줄링해야 하는 대상은 CPU Burst이다. 어떤 프로세스가 CPU Burst를 맞이하게 됐을 때 CPU 타임을 프로세스에게 어떻게 할당해줄 것인가가 스케줄링에 있어 중요한 문제가 된다.
Batch OS의 스케줄링
Batch OS에서는 어떤 Job이 완전히 수행을 끝날 때까지 컴퓨터 시스템을 장악해서 썼기 때문에 CPU Burst 타임과 I/O Burst 타임을 구별할 필요가 없었다. 멀티 프로그램이 멀티 태스킹을 하지 않았기 때문에 Job의 전체 라이프 타임 단위로 스케줄링을 했다. 그런 관점에서 Job의 스케줄링과 멀티태스킹 OS에서의 I/O Burst 스케줄링, 프로세스 스케줄링은 차이가 있다.
CPU Execution 타임의 할당 문제
CPU Burst 사이즈를 보고 거기에 맞게 스케줄링해야 최적화된 스케줄링 결과 성능 결과를 얻을 수 있다.
초창키 컴퓨터 과학자들은 프로그램의 수행에서 CPU Burst 타임이 어떻게 되는지 연구를 많이 했다. 주로 프로파일링을 했는데 주로 한 4ms 내외의 CPU Burst 사이즈의 빈도가 가장 많았다. 그것보다 작은 것은 좀 적었고 큰 것은 별로 없었다.
만약 CPU Burst 타임이 40ms 이상 커진다는 것은 프로그램을 수행하는 데 I/O를 거의 안 한다는 것을 의미한다. 그런데 이런 프로그램은 굉장히 드물다. 이런 경우는 Computation intensive한 과학 기술 연산 같은 응용이 된다.
어떤 프로세스는 크게 두 가지로 나뉜다.
CPU Intensive 프로세스 / CPU Bound 프로세스
CPU Burst 사이즈가 큰 프로세스
사용자와 인터랙션이 거의 없다. 사용자가 기대하는 것은 Response 타임이 아니라 Throughput이다.
*Throughput: 단위 시간당 컴퓨터 시스템이 끝낸 연산의 개수
즉, CPU Intensive 프로세스의 성능 척도는 Throughput이 된다.
I/O Intensive 프로세스 / CPU Bound 프로세스
I/O Waiting 타임이 긴 프로세스
사용자와 인터랙션이 많다. 사용자는 빠른 Response 타임을 기대한다.
즉, I/O Intensive 프로세스에서는 Response 타임이 짧아지는 것을 중요한 성능 척도로 생각한다.
두 프로세스의 목표는 사실 상충한다. CPU 스케줄러는 둘 사이에서 균형을 잘 맞춰야 한다.
스케줄링이 일어나는 상황, 즉 Ready 상태에 있는 프로세스 중에서 CPU를 사용할 프로세스를 하나 선택하는 상황, CPU 스케줄러가 트리거되는 상황은 다음과 같다.
- 프로세스가 Running 상태에 있다가 Waiting 상태로 갈 때 (자발적 CPU 포기, 비선점적)
- 프로세스가 Waiting 상태에 있다가 자기가 기대하던 이벤트를 받게 되어 Ready 상태로 갈 때 (선점적)
- 프로세스가 Running 상태에 있다가 비동기적인 하드웨어 인터럽트를 만나서 선점적으로 Ready 상태로 갈 때 (선점적)
- 프로세스가 Running 상태에 있다가 수행이 종료되어 exit을 했을 때 (비선점적)