[ 운영 체제 6-2강. 프로세스 스케줄링 ]

스케줄링 알고리즘

Preemptive 스케줄링 ( 선점 )

( key idea : 돌아가면서 n초씩 쓰자! )
스케줄링 기준 : “도착 시간”
“자원 사용 제.한.시.간 (=time quantum)”이 있다

( 특정 자원이 독점 방지! )
단점 : Context Switch, Overhead가 큼
적합 : 대화형, 시분할 시스템
결국, Time quantum(제한 시간)이 시스템 성능에 핵심
- 너무 클 경우 : FCFS ( 사실상 “선착순” )
- 너무 작을 경우 : Processor Sharing ( 사실상 “동시” )

Non-preemptive 스케줄링 ( 비선점 )
key idea : 난 금방 끝낼 수 있는데…이 만큼이나 기다리라고??

( 짧은 애를 먼저 뺴주자! )
스케줄링 기준 : “Burst Time”이 가장 작은 프로세스부터

( = SJF (Shortest Job First) 스케줄링 )
장/단점
- 장점 :
  - 1) 평균 대기시간(WT) 최소화
  - 2) 시스템 내 프로세스 수 최소화
    
    ( 스케줄링 부하 감소 & 메모리 감소 -> 효율 UP )
  - 3) 많은 프로세스들에 “빠른 응답 시간 제공”
- 단점 :
  - 1) Starvation (무한 대기) 현상
    
    ( 나 오래걸리는 작업이라고…계속 기다리라고?? )
    
    ( 해결 : Aging 등 … HRRN )
  - 2) 정확한 실행시간 알 수 X
    
    ( 실행 시간 예측 기법이 필요함 )

SPN의 변형 ! “남은 시간” 이 가장 적은 애를 선택
Preemptive scheduling ( 선점 )
- 잔여 실행 시간 더 적은 또 다른 process가 ready가 되면, 쓰던거 뺏길 수도!
장/단점
- 장점 : SPN의 장점 극대화
- 단점 : 총 실행 시간 & 잔여 실행 시간 예측/추적 계속해야!
  
  ( 구현/사용이 비현실적…. )

Response Ratio (응답률) = (WT+BT) / BT

공평성 ( Fairness )에 초점

효율성/성능 ( Efficiency / Performance )에 초점

( 공통 문제점 : 실행 시간 예측 부하 + 힘들고, 정확하지도 않음 )

이를 보안하기 위한 MLQ & MFQ

( 성능/효율성 높이는 건 좋은데…. 실행시간(BT)를 예측해야한다고! 이거 없이 안될까?? )

작업 (or 우선 순위)별 별도의 ready queue를 가진다
- 최초 배정된 queue로 fix됨
- 각각의 queue는 “자신 만의 스케줄링 기법” 가짐
queue 사이에는, “우선 순위 기반의 스케줄링”
장/단점
- 장점 : 빠른 응답시간(?)
  - 우선 순위 높은 애들은 빠르겠지만….
- 단점 : 여러 queue