[Operation Systems] Limited Direct Execution

왜 Limited 되어야 하는가?

 

Limited되지 않는다면, OS와 Program은 동등한 계층(hierarchy)를 갖는다.

따라서 OS는 Program을 감시하거나 동작을 제어할 수 없다.

 

만약 Program이 무한히 돌고 있다면(intended하든, unintended하든지간에), OS는 주도권을 갖을 수 없으며 

멈추는 방법은 오로지 restart하나 뿐일 것이다.

 

또한 접근하지 않아야 할 영역에도 무차별적으로 접근하여 Process간 Protection이 전혀 존재하지 않는다.

 

따라서 OS가 다른 모든 process보다 높은 곳에서 process들을 관리하는 최상위 계층에 존재해서 이들을 제어할 수 있어야 한다.

 

Limited Direct Execution

 

Hardware는 OS에게 두 가지 execution mode를 제공한다.

 

User Mode와 Kernel Mode가 그것이다.

 

User Mode: 제한된(restricted) 동작만을 할 수 있으며, kernel 모드에 진입해야 할 경우에는 system call을 이용해야 한다.

그렇지 않을 경우 OS는 Exception을 발생시켜 Process를 Kill한다.

 

Kernel Mode: OS가 동작하는 Mode이다.

Privileged Operation(ex- I/O request)을 포함하여 모든 동작을 제한받지 않고 수행할 수 있는 Mode.

 

Process는 User Mode에서 실행되며, 제한된 동작을 실행하고 싶을 떄에는 운영체제에 system call을 이용하여 Kernel Mode에 진입해야 한다.

 

Scenario

 

Process를 실행시키고 Kernel Mode로 진입했다가 User Mode로 다시 돌아오는 과정을 생각해 보자.

 

1. Program을 실행하기 위한 Machine State를 설정한다. (Kernel Mode)

2. return-from-trap 을 발생시킨다 (Kernel Mode)

3. Kernel Stack으로부터 register 정보를 복구한다 (Hardware)

4. User Mode로 진입하고 main()으로 Jump 한다 (Hardware)

5. Running... (User Mode)

6. System call 발생으로 Trap 발생 (User Mode)

7. Kernel Stack에 register 정보 저장 (Hardware)

8. Kernel Mode로 진입하고 Trap Handler로 Jump 한다. (Hardware)

9. Handle Trap( Do work of system call) (Kernel Mode)

10. Kernel Mode에서의 작업이 모두 끝났으므로 다시 return-from-trap 발생 (Kernel Mode)

 

3번으로 돌아가서 Process가 끝날 때까지 반복

 

(그러나 이것은 문제를 가지고 있음에 주의하자- 불완전)

 

So, What's the problem?

 

Process가 두개 이상일 때를 상상해 보자.

 

아마 그것은 별로 어렵지 않을 것이다.

 

A가 실행중이라면 정보를 저장하고 잠시 멈춘 뒤, B의 정보를 복구해서 다시 실행하고... 이런 방법을 유지시키면 될 것이다.

 

그러나 주의하여 다시 Scenario를 살펴 보자.

 

단순히 어떤 Process가 제한된 상태로 실행중일 뿐, OS는 실행되고 있지 않다.

 

즉 여전히 OS는 process가 실행중일 때 간섭할 수 없는 상태이다.

 

Past Solution: Cooperative Approach

 

과거의 매킨토시 OS에서 사용한 방법이다.

 

단순히 OS는 언젠가 Process가 System call을 호출할 것이라고 믿고 기다리는 것이다.

 

그리고 System call이 발생하면 OS가 다른 작업을 실행할 것인지를 결정한다.

 

물론 Process가 System call을 호출하지 않는다면 역시 OS는 process에 간섭할 기회조차 갖지 못하고 단지 process가 끝날 때까지 기다린다.

 

게다가, 그 Process가 악의적이거나 버그로 가득 찼다면 process를 종료한 유일한 방법은 reboot 뿐이다.

 

Modern Solution: Non-Cooperative Approach

 

Process가 System call을 호출하지 않더라도 OS는 주도권을 가질 수 있어야 한다.

(그래야 최상위 계급에 위치한 것이라 할 수 있을 것이다.)

 

Cooperative Approach의 치명적 단점은 아주 간단히 해결된다.

 

바로 Timer를 사용해 Interrupt를 주기적으로 발생시키는 것이다.

 

Hardware에서 일정 milliseconds마다 Interrupt를 발생시켜 일정 주기마다 OS는 주도권을 갖을 수 있다.

(그리고 다음에 실행될 Process를 결정할 수 있다.)

 

OS는 timer interrupt가 발생했을 때 실행할 코드에 대한 정보를 가지고 있으며

Booting단계에서 timer를 Privileged Operation으로써 실행시킨다.

 

Context Switch

 

Scenario의 3번과 8번에 주목하라.

 

Interrupt가 발생했을 때, 그 정보들은 overwrite될 지도 모르기 때문에 별도의 data-structure에 안전하게 저장되고

다시 running될 때, 다시 복구되어 계속해서 정상적인 execution을 하도록 보장되어야 한다.

 

이러한 일련의 작업들을 Context Switch라고 한다.

 

Scenario: When Current Process is decided to change to another by OS Scheduler

 

Process A 실행 도중, OS Scheduler가 Process B로 Context Switch 하기로 결정했다고 가정해 보자.

 

1. Timer Interrupt 발생 (Hardware)

2. register(A) 정보를 Kernel Stack(A)에 저장 (Hardware)

3. Kernel Mode로 이동하고 trap Handler로 Jump한다 (Hardware)

4. Handle the trap 하고 switching 실행 (Kernel Mode)

5. register(A)정보를 proc-struct(A)에 저장 (Kernel Mode)

   register(B)정보를 proc-struct(B)로 부터 복구 (Kernel Mode)

   Kernel stack(B)로 Kernel switch (Kernel Mode)

6. return-from-trap(B) (Kernel Mode)

7. register(B)정보를 Kernel Stack(B)로부터 복구 (Hardware)

8. User Mode로 이동하고 B의 Program Counter가 가리키는 곳으로 이동 (Hardware)

9. Process B 실행

 

* 5에서 proc-struct(PCB)는 OS에 따라 Kernel-stack이 될 수도 있다.

 

* PCB (Process Control Block)

* CPU에 의해 실행중인 특정한 process를 관리할 필요가 있는 정보를 포함하는 OS Kernel의 data-structure.

 

이처럼 Limited Direct Execution은 Mode를 전환하면서 register를 복구하거나 저장하기 때문에 Overhead가 발생하여

(Non-Limited) Direct Execution 보다 느리지만, 속도를 약간 포기함으로써 다양한 장점을 얻을 수 있다.

 

Scheduling을 포함한 다양한 방법들의 적절한 사용이 Overhead를 줄이는 데 도움이 될 수 있다.

 

--------------------------------------------------

 

Reference

 

Operating Systems: Three Easy Pieces (Remzi H. Arpaci-Dusesdau, Andrea C. Arpaci-Dusesdau)