Operating System - CPU Virtualization(2)

CPU virtualization

: OS에 구현 하는데, time sharing이 대표적

--> 구현을 위해 필요한 두 가지

1. low level mechanism(how)

: 수행 중인 프로세스를 멈추고, 다른 프로세스를 수행할 수 있게 하는 매커니즘

ex. context switch

 

2. policy

: 다음 사용권한을 어떻게 줄지 결정해야 하는 policy

ex. scheduling policies

 

 

프로세스

: 하드디스크에 있던 데이터가 메모리에 올라 실행할 수 있게 된 상태 - 즉, 메모리에 있다

life 있음, 메모리에 올라오면 탄생, 이후 수행

 

프로그램

: 코드(명령)의 집합 '실행가능 파일' - 하드디스크에 즉 디스크에 존재

life 없음, 그냥 존재

 

process creation

--> 프로그램코드를 메모리에 로드, fetch

--> OS는 프로세스 로딩을 할때 다 되서 움직이기에 lazily하게 한다 볼 수

--> 런타임 스택 할당

--> 프로그램의 힙이 생성

--> 작동

 

process state

3-state model (가장 기본적 형태)

: 프로세스가 세 개의 서로 다른 state를 가지고 있다

Running / Ready / Blocked(wait)

 

Running

: 프로세스가 수행되기 위한 모든 리소스와 cpu권한 또한 갖고 있는 상태

 

Ready

: 프로세스 수행을 위해 필요한 모든 리소스는 가졌지만 cpu에 대한 권한은 없는 상태

--> time slicer가 끝나 다른 프로세스에 권한을 남기고 대기중인 상태이고, 권한만 주면 바로 running

 

Blocked

: 프로세스 수행에 대한 리소스도 없고, cpu에 대한 권한도 없다

--> I/O device에서 요청을 기다릴 때가 대표적으로, 다음 코드를 수행하기 위해 외부 I/O 디바이스에서 와야만 ready상태가 되고, ready queue에서 대기한 후 이후 cpu 권한을 얻어야 running 가능

5-state model

: 3-state model에서 new와 exit가 추가된 모델

--> 올라와도 된다는 허락을 받은 상태가 new 상태

--> 이후 ready queue에 들어가 running

--> new state와 같이 프로세스 생성은 fork()라는 시스템 콜을 통해 가능

Exit state?

--> PCB(Process Control Block)에서 exit 되면 유저 영역 메모리에 올라왔던 프로세스도 사라지고, OS도 이에 필요한 데이터 지움

Zomebie state?

--> OS가 이미 유저영역 메모리에서 지워진 프로세스에 필요한 데이터를 버리지 않고 갖고있는 상태

Orphan state?

--> child 프로세스 죽지 않았지만 parent 프로세스가 죽은 경우(실수인 경우가 많음)

Preemption

: 멈추는 것, 현재 수행되는 것을 멈출 수 있는지 없는지

--> 즉, running state를 중단하고 ready state로 옮길 수 있는지

 

7-state model

--> 메모리 저장공간이 충분치 않아서 수행되어야 할 프로세스가 다 들어와있지 않을 때 수행하는 swapping

--> 프로세스 파트를 메인 메모리와 디스크 사이에서 이동하는 것

--> 즉 일시적으로 메모리의 프로세스를 디스크에 내려보내 놓는 것

--> suspend queue 관리 필요

--> 가능한 swapping은 일어나지 않는게 좋다(속도 측면에서 디스크 접근이 아주 느리기에)

PCB(Process Control Block) - 개별 프로세스에 대한 정보를 갖고 있는 구조

: OS가 프로세스 멈추고 다른 프로세스로 갈때 멈춘 프로세스의 상태를 지니고 있어야 하고, 재수행 시 세팅할 때 상태 데이터를 넣어놓는 곳이 PCB

--> 이렇게 저장시켜놓고 사용하다가 exit 되면 zomebie나 orphan이 아닌 경우 데이터 없앰

 

PCB내 데이터 중에선 Context가 핵심적인 정보

--> stop시켰을 때의 레지스터 정보들, 어디 까지 수행했는지 값 등등

--> PID, Process state, Program Counter, CPU registers 등

Direct Execution

: CPU가 직접 program을 실행하는 것

--> OS가 어느 제어도 하지않음, 실행 하면 그 이후부턴 그냥 CPU가 끝날 때 까지 제어

문제점이 있다

: 프로세스 실행 중 OS가 간접하지 못할 때의 문제점?

--> 1. Restricted operations - 제한된 활동밖에 하지 못함

--> 2. Switching between processes - 실행 중간에 멈추고, 스위칭이 이루어지는데 멈출수가 없다 - 즉, cpu virtualization을 위해 time sharing을 쓰지 못한다는 것

 

LDE(Limited Direct Execution)

: 제한된 Direct Execution

--> LDE는 유저가 OS가 처리하는 환경에 치명적 결과를 일으키는 명령으로 부터 보호하기 위해 존재

--> 즉, 유저가 무언가를 요청을 해도 LDE를 통해 OS가 이를 실행하게 해준다

--> ex. scanf를 할 때 I/O 디바이스 출력하는데 있어 OS가 대신해준다 이 외에도 메모리 접근 등

 

만약, 프로세스가 디스크 읽어들임과 같은 부분에 대한 처리를 원한다면?

--> '시스템 콜'을 통해서

--> trap exception을 주면(의도적) mode bit이 0으로 바뀌고(커널모드) 시스템 콜이 가리키는 function들이 OS내 스택에 있다 --> 이를 수행시켜서 해결하고 mode bit 다시 1로 변경

trap이 실행되면, PCB와 같은 커널스택에 접근

OS가 프로세스 switch를 위해 CPU에 대한 권한을 얻는 방법?

 - A Cooperative Approach

: 시스템 콜을 기다림(유저가 cpu권한 놓을 때 까지 기다림)

--> 예를 들어 Yield와 같은 시스템콜을 통해 cpu에 대한 권한을 놓는다

--> 무한 루프의 문제가 생기면? OS는 그냥 기다릴 수 밖에 없어 개입이 안되기에 재부팅할 수 밖에 없다

 

 - A Non - Cooperative Approach

: OS가 기다리지 않고 필요할 때 마다 작동을 멈추고 권한을 가져감

--> 예를 들어 timer interrupt를 통해 정해진 주기마다 cpu권한을 가져가는 것

 

PCB는 OS의 데이터를 저장하는 곳이며 프로세스에 대한 모든 정보를 저장해놓음

--> context가 저장

context switching 너무 자주 일어나면 효율이 떨어진다(time slice를 너무 빈번히 짧게 잡으면 떨어진다) - 효율을 높이기 위해 time slicing을 하는 것인데 빈번하면 효율이 떨어진다? 일종의 trade-off 관계