[운영체제]process scheduling

정태규·2023년 4월 14일
0

운영체제

목록 보기
5/20

Process scheduling

프로세스 스케줄링이란 무엇일까??

각 process는 자기 자신의 address space를 갖고 있다.

만약 시스템이 여러 프로세스를 갖는다면

위와 같을 것이다.

multiple process들이 여러개의 프로세서에서 돌아간다면 프로세서가 프로세스 하나씩 맡아서 실행시키면 된다.

하지만, 프로세서가 하나라면 어떻게 여러 프로세스들을 실행 시킬 수가 있을까??

OS가 바로 이런점을 해결 해준다.
OS가 virtualization을 통해서 각각의 프로세스가 address space를 가지고 있도록 만들어준다.

요약해서 말하자면, OS가 scheduling을 통해서 process마다 돌아가면서 CPU를 사용할 수 있도록 스케줄을 짜준다.

하지만, process를 교체하는 과정이 느리면 우리가 사용할때 불편할 것이다.

동시에 모든 process를 사용하는 것처럼 느끼려면 프로세스들을 빠르게 스위치 시키는 것이 중요하다.

process scheduler는 cpu에서 다음 실행을 위해 준비된 프로세스들 중 선택하는 역할을 한다.

우리가 알아볼 내용은 다음과 같다.

  1. 프로세스들이 스위치 되는 방법
  2. 스케줄링을 위해 사용 가능한 프로세스를 찾고 관리하는 방법
  3. 실행을 위한 다음 프로세스를 선택하는 방법

Parallelism vs Concurrency

scheduler는 single processor에서도 병렬처리 없이 concurrency(동시성)을 갖게 해준다.

현대 OS들의 Time Sharing

OS는 hardware의 timer를 사용해서 illusion을 만든다.

  • OS가 정해진 시간 이후에 interrupt를 생성하기 위해서 timer를 설정한다.
  • OS가 프로세서에게 어플리케이션을 할당한다.
  • 어플리케이션 프로세스는 CPU cycle을 소모한다.
  • 타이머가 만료되면, 타이머는 timer interrupt를 생성한다.
  • 프로세서는 OS에 속한 timer interrupt handler로 점프한다.
  • scheduler는 다음 실행할 process를 선택한다.
  • 1번부터 반복

Machanism vs Policy

Mechanism

  • 어떻게 할 수 있는지?
  • policy들을 구현하기 위한 도구
  • e.g) 시스템에서 multiple process들을 관리하는 방법

Policy

  • 무엇을 해야 하는지?

  • 리소스를 할당하고 관리하는 것을 어떻게 할지 결정

    CPU time도 resource

  • e.g)다음 실행할 process들이 무엇인가??

policy를 분리한 mechanism

  • OS 디자인의 핵심 원칙이다.
  • policy는 작업량이나, 장소, 시간에 흐름에 따라 변경될 수 있다.
  • policy와 분리되어 있는 일반적인 mechanism이 바람직하다.
  • 보다 모듈화된 OS를 구축할 수 있다.
  • 확장할수 있는 시스템 가능(e.g.,유저 특화 policy)

Context Switch

  • CPU가 다른 process로 스위치할때, 시스템은 현재 프로세스의 상태를 저장해야하고, 다음 프로세스의 상태를 load해야 한다.

  • 프로세스의 Context는 PCB(process control box)안에 나와 있다.

  • context-switch time은 overhead이다.
    *overhead: 처리하는 데 걸리는 시간,메모리

    시스템은 스위치 하는중에는 유용하게 작업을 하지 않는다.
    OS와 PCB가 복잡할수록 context switch는 더 길어진다.

  • context-switch 시간은 hardware 지원에 따라 달려있다.

    몇몇 하드웨어(SUN UltraSPARC) CPU하나당 레지스터들의 집합 여러개를 제공한다.
    -> CPU에서 multiple context들을 유지할 수 있다.

Process에서 process로의 context switch

  1. process p0를 실행하다가 interrupt나 system call이 발생했다.
  2. 그러면 p0를 PCB0에 p0의 상태를 저장한다.
  3. 그러고 process p1을 PCB1으로 부터 상태를 불러온다.
  4. p1을 실행한다.
  5. interrupt나 system call이 발생하면 PCB1에 p1의 상태를 저장한다.
  6. 다시 PCB0의 상태를 불러오고 p0가 실행된다.

PCB(process Control block)

  • process에 관한 모든 정보를 포함한다.

scheduling queues

  • ready queue: 실행되기를 기다리는 process들

  • device queue: 위에 그림의 disk가 이에 해당하고, interrupt가 발생했을때, 실행되는 queue

  • 처음에 process가 들어오면 ready queue에 놓인다. process가 scheduler에게 선택되어 CPU에서 실행되다보면 interrupt가 발생할 수 있다.
    I/O interrupt나, time slice expired(tick, quantum등을 다 썼을경우), fork,wait interrupt등이 그 예이다.
    interrupt가 발생하면 그에 해당하는 interrupt queue에 추가되고 waiting 상태로 기다린다. interrupt handler routine이 끝나면, 다시 ready queue로 돌아가고 우선순위에 따라 ready queue에서 process가 실행된다.
    만약에 interrupt가 발생하던중 다시 interrupt가 발생하면 , interrupt queue에 순서대로 추가된다.

0개의 댓글