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 관계
