[운영체제] Limited Direct Execution(LDE) 메커니즘

[ 어떻게 하면 CPU를 효율적으로 가상화하고 제어할까? ]

 

 OS는 time sharing을 통해 물리적인 CPU를 공유함으로써 각 process에게 가상의 CPU를 제공해야 합니다. 

 

 이때 두 가지 문제가 있습니다. 

 

1. Performance: 추가적인 overhead 없이 어떻게 virtualization을 구현해야할까?

 

2. Control: 어떻게 하면 CPU에 대한 제어를 유지하면서 효율적으로 process를 실행할까?

( CPU 제어 없이는 process가 영원히 실행하여 기계를 장악하거나, 접근해서는 안되는 정보에 접근함 )

 

 

 

 

[ Direct Execution ]

 

 direct execution은 program을 CPU 위에서 직접 실행하여 한 번 수행하면 종료될 때까지 수행하는 방법입니다. 

 

 이때 실행중인 program에 아무런 제약이 없어, program에 문제가 생기면 OS는 통제권을 잃고 단지 library에 불과하게 됩니다. 

 

 

<Problem 1>

 OS 가 process 생성 후 main() 호출 실행-> process는 CPU 통제권 얻음 -> process의 program에서 main() 실행 -> 만약 이 프로그램이 잘못된 작업을 수행하여 kernel에서 문제가 발생하면> -> OS 는 통제권을 다시 얻지 못함 -> Problem !!!

 

<Problem 2>

 OS 가 process 생성 후 main() 호출 실행-> process는 CPU 통제권 얻음 -> process의 program에서 main() 실행 -> 만약 이 프로그램이 영원히 실행되면? -> OS 는 통제권을 다시 얻지 못함 -> Problem !!!

 

 

 

 

 

[ Problem 1: Restricted Operation ]

 

 만약 process가 disk에 I/O request를 보낸다거나, CPU나 memory같은 더 많은 시스템 리소스에 접근하려고 하는 Restricted Operation을 수행하려고 한다면, kernel에 문제가 생길 것입니다. 

 

 그 해결책으로 모든 권한을 부여하는 것도 있지만 그렇게되면 프로세스가 하드웨어 리소스를 마음대로 접근할 수 있기 때문에 보호 기능이 손실되게 됩니다. 그것보다 더 효율적인 방법이 있습니다. 

 

• Solution: Protected control transfer 사용

 프로세스를 user mode와 kernel mode로 분류하여 더 효율적으로 돌아갈 수 있게 하는 방법입니다. 

 

 user mode에선 application은 하드웨어 리소스에 대한 접근 권한이 없지만,

 kernel mode에선 OS가 직접 하드웨어 리소스에 접근할 수 있습니다. 

 

 

 이때 user mode의 프로세스가 kernel mode에서 수행 가능한 작업을 원할 땐 System Call을 통해 kernel은 user program에게 파일 시스템 접근, process 생성 및 파괴, 다른 process와의 communicating, 더 많은 메모리 할당 등과 같은 특정 기능을 제공합니다. 

 

 System call이 호출되면 trap 명령으로 kernel mode로 권한을 바꿔 작업을 수행하고, 수행한 후 OS는 return-from-trap 명령으로 user mode로 돌아옵니다. 

 

 즉, 프로세스를 user mode와 kernel mode 분류하여 System call을 호출하면 trap 명령으로 kernel mode 로 전환 후 작업을 수행하면 OS가 return-from-trap 명령으로 다시 user mode로 돌아오는 것입니다. 

 

 그렇다면 OS는 trap을 처리하기 위해 어떤 것을 사용할까요? 바로 trap table입니다.  

 

 trap table은 trap handler들의 주소를 갖고 있는 테이블로, OS가 trap handler의 위치를 하드웨어에게 알려줍니다.

 

 

• Limited Direction Execution

 

 

 부팅되고 나면 trap table이 초기화되고, OS는 하드웨어에게 trap handler의 위치(trap table)을 알려줍니다.

 

 OS가 process를 생성하고 나면 return-from-trap 명령으로 user mode로 전환한 후, user mode에서 process는 program을 실행한 뒤 system call 이 호출되면 trap 명령으로 OS, 즉 kernel mode로 전환합니다. 

 

 OS는 user가 호출한 시스템 콜을 수행한 뒤, 다시 user mode로 전환하여 process는 program을 종료한 뒤 exit() 시스템 콜을 통해 trap 명령을 하여 OS로 돌아갑니다. 

 

 

 

 

 

[ Problem 2: Switching Between Processes ]

 

 두 번째 문제점이 process가 영원히 실행하여 OS가 CPU 통제권을 다시 얻지 못하는 상황이었습니다. 

 

 그렇다면 어떻게 OS는 다시 CPU 통제권을 얻어 다른 process로 switch 할 수 있을까요?

 

 

• A Cooperative Approach: Wait for system calls

 

 프로세스가 yield() 와 같은 시스템 콜을 호출하여 CPU 통제권을 스스로 놓으면 그제서야 OS가 다른 작업을 수행하는 것입니다. 

 

 한 마디로 OS 입장에서 process가 CPU 통제권을 스스로 놓는 system call을 호출하기를 기다리는 것입니다. 

 

 하지만, 이 방법 역시 프로세스가 무한 루프에 걸리게 되면 기계를 리부팅해야되기 때문에 여전히 문제점을 해결할 수 없습니다. 

 

 

 

 

• A Non-Cooperative Approach: The OS takes control

 

 이 방식은 timer interrupt를 통해 OS 가 직접 CPU 통제권을 가져오는 방식입니다. 

 

 OS는 timer를 시작하여, timer는 일정한 시간마다 interrupt를 걸어주어 현재 실행중인 process를 중단시켜 OS가 다시 CPU 통제권을 뺏어옵니다. 

 

 이때 Scheduler가 현재 process를 계속 실행할지, 다른 process로 바꿀지 결정하는 Scheduling을 합니다. 

 

 만약 바꾸기로 결정했다면, 그때 OS가 context switching을 통해 다른 process로 변경해주는 것입니다. 

 

 Context switching은 어셈블리 코드로 이루어져 있으며, 먼저 현재 프로세스의 General purpose registers, PC, kernel stack pointer와 같은 register 값들을 나중에 다시 실행하기 위해 kernel stack에 저장합니다.

 

 이 프로세스가 다시 실행될 때 kernel stack에 저장한 프로세스에 대한 정보를 복구하게 됩니다. 

 

 

 

• Limited Direct Execution (Timer Inerrupt)