일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- pwnable.kr
- 운영체제
- 완전탐색
- 김건우
- 시뮬레이션
- 동기화문제
- 컴공복전
- 프로세스
- 데드락
- 백준
- samsung research
- 알고리즘
- 백트래킹
- 삼성기출
- fork
- BFS
- 구현
- Deadlock
- paging
- dfs
- higunnew
- segmentation
- ascii_easy
- Memory Management
- BOJ
- 가상메모리
- 스케줄링
- Brute Force
- 삼성리서치
- exec
- Today
- Total
gunnew의 잡설
6-1강. CPU 스케줄링 본문
CPU 스케줄링을 설명하기에 앞서 그 배경에 대해 잠깐 설명하자. 프로그램이 실행이 되면 어떤 프로그램이든 간에 다음과 같은 과정을 따라 수행이 된다. “load store”, “add store”와 같은 것들은 CPU에서의 instruction 즉, 기계어이다. 그리고 중간중간 I/O를 위한 작업이 있다. 그러니까 프로그램의 일반적인 구성상 CPU를 썼다가 I/O를 했다가 하며 반복적으로 번갈아 가며 수행될 것이다. 여기서 일련의 CPU instruction을 수행하는 단계를 CPU burst라고 하고 I/O를 수행하는 단계를 I/O burst라고 한다.
다음은 일반적인 job들의 CPU-burst time의 분포를 그린 것이다. CPU burst와 I/O burst의 수행 횟수를 비교해봤더니 I/O burst가 중간에 많이 일어나게 되어 CPU burst의 지속 기간이 짧은 job들이 월등히 많았고, CPU intensive한 job들은 적었다. 전자를 I/O bound job이라 하며 사람과 interact 하는 job(Interactive job)이라 하며 후자를 CPU bound job이라 한다. 그러나 이렇다고 해서 CPU를 많이 쓰는 job이 I/O bound job이라고 단정할 수는 없다. 단순히 CPU-burst time의 지속 시간이 짧은 job들이 I/O bound job이며 이들의 빈도가 많았을 뿐이다.
여기서 CPU 스케줄링이 필요한 이유가 대두된다. CPU bound job은 빈도도 낮으며 한 번 CPU를 쓰면 오래 쓴다. 그러나 I/O bound job의 경우 CPU를 짧게 여러 번 사용한다. 따라서 두 job들이 맞물려 있다면 I/O bound job을 적절히 수행할 수 없게 되며 사용자가 답답함을 느끼게 될 것이다. 따라서 적절한 관리가 필요하다.
그러나 무조건 공평하게 CPU를 분배한다고 해결되는 것은 아닐 것이다. 사용자의 입장에서는 무조건 공평한 것 보다는 사용자와 가까운, 즉, Interactive job에게 더 우선적으로 스케줄링을 해주는 것이 좋을 것이다. 그러니까 Interactive job이 너무 오래 기다리지 않게 하도록 하는 것, 이것이 바로 CPU 스케줄링의 핵심이다.
* CPU Scheduler & Dispatcher에 대한 간단한 설명 |
CPU scheduler는 누구에게 CPU를 줄지 결정한다. 스케줄러라 하니 꼭 무슨 소프트웨어나 하드웨어를 일컫는 것 같지만 사실은 운영체제 커널 내부에 있는 스케줄링 코드 부분을 말한다.
Dispatcher도 하드웨어도 아니며 소프트웨어도 아니다. CPU를 누구에게 줄 지 결정했으면 그 프로세스에게 넘겨주는 운영체제 커널 코드를 말한다. CPU를 넘겨줄 때 해야 되는 것이 있었지 않은가? 바로 문맥 저장! 그러니까 프로세스의 Context를 저장하고, 새로이 CPU를 넘겨받을 프로세스의 Context를 펼쳐 놓아야 한다. CPU register 값 세팅하고 Program Counter에 앞으로 실행할 코드 영역 가져다 놓고… 이후 CPU를 넘겨주는 작업을 담당한다.
CPU 스케줄링은 언제 필요한가? |
그렇다면 CPU 스케줄링은 언제 필요한가?
1. Running -> Blocked |
I/O와 같이 어차피 당장 CPU를 가지고 있어도 무언가를 할 수 없을 때 스케줄러는 스케줄링을 한다.
2. Running -> Ready |
나는 CPU를 계속 쓰고 싶으나 무한정 시간을 제공할 수는 없다. Timer가 존재하기 때문인데 이 Timer가 할당한 시간이 만료가 되어 Timer interrupt가 발생할 때이다.
3. Blocked -> Ready |
I/O를 요청했던 프로세스의 I/O 작업이 끝난 경우이다. 그런데 지금까지는 I/O가 끝났더라도 바로 running 되는 것이 아니었다. 일반적으로 이미 CPU를 소유하고 있던 프로세스에게 다시 넘어가는데 이 경우는 Timer에 기반한 스케줄링한 경우이다. 만약 우선순위에 기반한 스케줄링이었고, 이전에 I/O 작업을 요청했던 프로세스의 I/O 작업이 끝난 그 프로세스가 우선순위가 가장 높았다면, 중간에 CPU를 빼앗겼던 프로세스의 시간이 남아있다 하더라도 우선순위가 가장 높은 프로세스로 CPU가 넘어간다. 이러한 이유로 I/O 작업 요청으로 인해 Blocked 상태였던 프로세스에서 Ready 상태로 넘어가는 때에 스케줄링이 필요하게 된다.
4. Terminate |
프로세스가 종료돼서 할 게 없을 때 넘겨준다. Terminate에 관한 내용은 지난 5강에서 이미 모두 설명하였다.
1번과 4번은 nonpreemptive(자진 반납), 2번과 3번은 preemptive(강제로 빼앗는) 스케줄링이라고 한다.
본 글들은 이화여대 반효경 교수님 2014학년도 1학기 운영체제 강의를 기반으로 작성됩니다.
링크 : http://www.kocw.net/home/search/kemView.do?kemId=1046323
'Operating System' 카테고리의 다른 글
6-3강. CPU 스케줄링 알고리즘(Cont'd) (0) | 2020.01.29 |
---|---|
6-2강. CPU 스케줄링 알고리즘 (1) | 2020.01.26 |
5-3강. 프로세스 간의 협력 (0) | 2020.01.24 |
5-2강. 프로세스와 관련한 시스템 콜 (2) | 2020.01.24 |
5-1강. 프로세스 관리(Process Management) (0) | 2020.01.23 |