대학생활/운영체제

04. LDE 제한적 직접 실행

celinayk 2023. 10. 10. 00:51
반응형

LDE

CPU를 가상화하기 위해 OS는 물리적인 CPU를 이용해 여러 프로세스를 동시에 실행해야 한다.

어떻게?

한 프로세스를 잠시 실행하고, 다른 프로세스를 다시 실행하는 것을 반복하는 time sharing을 이용하는 것

이 때 performance(추가적인 overhead를 줄이면서 virtualize)와 control(OS가 process를 어떻게 control 할 것인가) 을 고려해야한다.

 

=> 프로그램을 최대한 빠르게 실행하기 위한 방법 중 하나가 LDE이다

 

direct execution은 프로그램을 CPU 위에 직접 실행하는 것 

위 Timeline처럼 단순해 보이지만 몇 가지 문제가 있다.

 

 

Problem #1 : 제한된 연산 Restricted Operations

direct execution은 빨라서 좋다. 하지만 I/O request가 발생한다면?

아무 프로세스나 I/O control을 하면서 H/W에 접근하면? 프로세스가 원하는 연산을 모두 다 허용한다면? protection을 보장할 수 없게 된다 

 

  • user mode & kernel mode

kernel mode 커널모드

hardward resources를 완전히 사용 가능, user mode에서는 불가능하다 

 

user mode 사용자 모드

사용자 코드에서 실행되는 코드는 제한 적인 일만 가능

사용자 모드일 때는 I/O 요청을 허용하지 않음 -> 요청을 한다면 Exception and kill 

trap 이라는 instruction을 이용해 kernel mode로 들어갈 수 있다. 사용이 다 끝나면 return-from-trap으로 다시 user mode로 돌아온다 

System call을 호출해 kernel mode의 권한으로 명령을 수행할 수 있다 

 

system call을 실행하기 위해서, 프로그램은 trap instruction을 실행해야 한다. 그러면 커널에 들어가 kernel mode로 권한 상승을 한다.(커널 안으로 분기 & 특권 수준을 커널 모드로 상향 조정) 

  • kernel stack

kernel mode로 들어갈 때 여러 data를 저장하기 위해 프로세스마다 kernel stack이 존재 

kernel mode에서만 접근 가능 

 

trap이 발생하면 PC, flag 그리고 다른 register를 kernel stack에 올린다. 그리고 다시 user mode로 돌아올 때 kernel stack에서 data를 다시 가져온다.

 

  • trap table & trap handle

당연히 trap table의 접근은 privileged operation이다. 따라서 user mode에서 trap table로 바로 접근할 수 없다.

커널은 부팅 시 trap table을 초기화하고, CPU는 그 주소를 기억한다. OS는 user의 trap을 다룰 수 있도록 trap handler를 가지고 있다.

 

 

 

trap으로 syscall을 호출하면 register를 kernel stack에 저장하고 trap handler로 jump 한다. 이후 syscall이 끝나면 return-from-trap으로 kernel stack에서 register를 가져오고 user mode로 돌아간다.

 

=> 프로세스가 실행하는 연산은 OS가 원치 않는 일이 있을 때 통제 할 수 있어야함 

 

 

 

Problem #2 : 프로세스 간 전환 Switching Between Processes

프로세스를 스위칭하는 경우를 고려해보자

  • A Cooperative Approach

process가 협력적인 행동만 한다고 가정하는 접근법이다

프로세스가 실행하다가 trap을 사용하는 경우(알아서 넘겨주거나 zero division trap) control을 가져와 다른 프로세스로 스위칭 한다

하지만 프로세스가 trap을 한 번도 실행하지 않고 무한히 loop을 돌면 control을 어떻게 다시 돌려놓지?

  • A Non-Cooperative Approach: The OS Takes Control

OS가 프로세스들을 믿지 않고 강제로 control을 가져올 수 있도록 하는 접근법이다

보통은 time interrupt를 이용한다. 프로세스가 돌다가 timer이 일정 주기로 interrupt를 발생시킨다. 그러면 OS가 interrupt handler를 위해 control을 가져올 수 있다 

  • Context Switching

timer interrupt를 이용해 프로세스 a에서 프로세스 b로 context가 스위치 되는 과정 

부팅 시 CPU가 syscall handler와 timer handler의 주소를 기억해둔다. 이후 OS가 timer를 실행한다

프로세스 A가 실행 중에 timer interrupt가 발생했다고 가정하자. 그럼 A의 register들을 A의 kernel stack에 저장한다. 이후 A는 kenrel mode가 되고, trap handler로 점프한다.

(여기서 레지스터를 저장하는 것은 H/W 스위치다.)

trap을 handle 하는 OS가 어떤 policy에 의해 A에서 B로 switch() 하기로 결정했다고 가정하자. 그럼 A의 register를 A의 프로세스 구조체(PCB 등을 포함)에 저장한다. 이후 B의 proc-struct에서 register를 가져와 return-from-trap을 실행한다.

(여기서 수행한 switch()는 S/W적인 동작이다.)

return-from-trap을 실행하면 H/W는 B의 kernel stack에서 register들을 가져오고, user mode로 들어간다.

이후 B의 Program counter가 가리키는 곳으로 jump 하고, 프로세스 B가 동작한다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

댓글수0