CPU를 컨트롤하여 가상화를 어떻게 효율적으로 하는가?

• OS는 time sharing을 통해서 physical CPU를 공유한다.
• 다룰 것
  • Preformance : 우리가 시스템에 과도한 오버헤드를 추가하지 않고 어떻게 가상화를 적용 시킬까?(오버헤드 : 특정 기능을 수행하는데 드는 간접적인 시간,메모리 등의 자원)
  • Control : 우리가 CPU 통제를 유지하면서 어떻게 프로세스를 효율적으로 수행 시킬까?

Direct Execution

• OS가 프로그램을 아무런 제한없이 CPU에서 실행시키는 것

• 프로그램을 CPU에 직접적으로 수행시키는 것

• 수행과정

1. 프로세스 list에 항목을 생성(OS)

2. 프로그램을 위한 메모리 할당(OS)

3. 메모리에 프로그램을 Load(OS)

4. argc/argv를 이용해 스택을 준비시킨다.(OS)

5. 레지스터를 비운다.(OS)

6. main() call을 수행한다.(OS)

7. main() 실행(program)

8. main()에서의 return 수행(program)

9. 프로세스의 메모리를 비워준다.(OS)

10. 프로세스 list를 제거해준다.(OS)

• 프로그램 실행에서 제한 없이는 OS는 아무것도 control할 수 없는 단지 "라이브러리"가 된다.

문제1. 제한된 작업

• 만일 프로세스가 1. 디스크에게 I/O request 2. CPU또는 메모리와 같은 시스템 자원에 대한 접근을 얻고 싶다면 어떻게 해야 하냐?

• 해결책 : protected control transfer를 이용한다.

  • User mode : application은 하드웨어 자원에 완전한 접근을 할 수 없다.
  • Kernel mode : OS는 기계의 모든 자원에 대한 접근이 가능하다.

System Call

• kernel을 1. 파일 시스템 접근, 2. 프로세스 생성및 삭제, 3. 다른 프로세스들과 소통, 4. 더 많은 메모리 할당과 같은 특정한 기능의 key pieces를 조심스럽게 노출시키는 것을 허락한다.
  ex) user mode : application(파일 접근)
  kernel mode : OS(sys_open(), sys_close(), sys_ready(),sys_write()...)

• Trap instruction

  • kernel로 jump한다.
  • 권한을 kernel mode로 상승시켜준다.

• Return from trap instruction

  • calling uset program으로 복귀
  • 권한을 다시 user mode로 낮춰 준다.

• Limited direction protocol
  
  

문제2. Switching Between Processes

• OS가 프로세스들 사이에 switching이 가능하게 어떻게 CPU로부터 control을 다시 얻을 수 있는가?
  • 협력적인 접근 방식 : system call을 기다린다.
  • 비협력적인 접근 방식 : OS가 control을 가진다.

cooperative approach : 시스템 콜을 기다린다

• 프로세스들은 yield와 같은 시스템 콜들을 통해서 주기적으로 CPU를 포기한다.
  • OS는 몇몇 다른 task를 수행하도록 결정한다.
  • application들 또한 법칙에 맞지않는 행위를 할 때마다 control을 OS로 transfer한다.
    • 0으로 나누기
    • 접근할 수 없는 메모리에 접근시도
• 프로세스는 무한루프에 빠진다. -> 기계를 재부팅해야함

non-cooperative approach : OS가 control을 가진다.

• timer interrupt
  • boot sequence동안, OS는 timer를 시작한다.
  • timer는 수많은 밀리초동안 interrupt를 발생시킨다.
  • interrupt가 발생할 때
    • 현재 수행중인 프로세스가 멈춘다.
    • 프로그램의 상태를 저장한다.
    • OS에서 이미 만들어진 interrupt handler가 동작한다.
• timmer interrupt는 OS가 CPU의 control를 다시 얻을 수 있게 해준다.

context를 저장하고 복원

• 스케줄러는 결정을 한다.
  • 현재 프로세스를 계속 수행할지, 또는 다른 것으로 바꿀지
  • 만일 바꾸기로 결정한다면 OS는 context switch를 시행한다.

Context Switch

• 어셈블리 코드로 짜여진 low-level 조각
  • 현재 프로세스(A)의 몇몇 레지스터 값을 현재 프로세스(A)의 커널 스택에 저장한다.
    • General purpose register
    • PC
    • kernel stack pointer
  • 커널 스택에서 곧 수행될 프로세스(B)중 일부를 복원한다.
  • 곧 수행될 프로세스를 위한 커널 스택으로 switch한다.
• limited direction execution protocol(Timer interrupt)

동시성이 걱정인가?

• interrupt 또는 trap handling이 작동하고 있을 때 다른 interrupt가 발생한다면?
• OS는 이런 사항을 다음과 같이 처리한다.
  • interrupt 수행중에 다른 interrupt를 비활성화한다.
  • 내부 데이터 구조에 대한 동시 접근을 보호하기 위한 고급 잠금체계를 이용한다.

PCB(Process Control Block)에 대한 추가적인 설명

• 운영체제가 프로세스를 제어하기 위해서 정보를 저장해 놓은 곳으로, 프로세스의 상태 정보를 저장해 놓은 구조체

• 프로세스의 상태 관리와 Context Switching을 위해 필요하다.

• PCB는 프로세스 생성시 만들어지며 주기억장치에 저장된다.

ex) 내가 음악을 듣고 유튜브를 보고 웹 서핑도 같이 하고 있는데 동시에 일어나는것 아님?
-> time sharing을 통해 여러 작업을 동시에 하는 것처럼 보임

그럼 유튜브를 보다가 웹서핑을 할 때 내가 유튜브를 보던 정보는?
-> PCB에 저장된다.

• 위의 예시처럼 한 프로세스가 다른 프로세스로 교체될 때 이전 작업에 대한 내용이 프로세스 단위로 PCB라는 Block에 정보가 저장된다.