OSTEP 06 Direct Execution
여러 작업들이 동시에 실행되는 것처럼 보이도록 하는 방법 -> CPU 시간을 나누어 쓰면 된다. 한 프로세스를 잠시동안 실행하고, 다른 프로세스를 또 잠깐 실행하고 하면서 물리적인 CPU를 공유한다. 이런 가상화 기법을 구현하기 위해서 몇가지 문제를 해결해야 한다.
- 성능 저하 -> 시스템에 과중한 오버헤드를 주지 않으면서 가상화를 구현할 수 있을까?
- 제어 문제 -> CPU에 대한 통제를 유지 + 효율적으로 프로세스를 실행 -> 제어권을 일으면 한 프로세스가 영원히 실행을 계속하게 될지도 모름.
1. 기본 원리: 제한적 직접 실행(Limited Direct Execution)
직접 실행 -> 프로그램을 CPU 상에서 그냥 실행시킨다.
이렇게 하면 프로그램이 운영체제가 원치않는 일을 하게 될 수 있다. 또 어떻게 프로그램의 실행을 중단하고 다른 프로세스로 전환시킬지 고민도 해야 한다. -> CPU 가상화에 필요한 시분할(time sharing) 기법.
따라서 제한적으로 프로그램을 실행시켜야 한다. 프로그램 실행에 제한을 두지 않으면 운영체제는 아무것도 제어할 수 없는 단순한 라이브러리가 된다.
2. 문제점 1: 제한된 연산
물리적인 CPU에서 직접 실행하면 빠르게 실행된다. 하지만 프로세스가 특수한 종류의 연산 (디스크 입출력 요청 및 CPU, 메모리 추가할당 요청 등)을 수행하길 원한다면? 예를 들어 파일에 대한 접근 권한을 부여하기 전에, 권한을 확인하는 파일 시스템을 만든다고 하자. 이 때 프로세스가 디스크에 대해 입출력하는 것을 제한하지 않으면 프로세스는 전체 디스크를 읽고 쓸 수 있기 때문에 검사하는 의미가 없다.
이 때문에 사용자 모드(user mode)와 커널 모드 (kernel mode) 가 도입되었다. user mode에서는 수행할 수 있는 작업에 제한을 두고, 제한된 작업은 kernel mode에서만 수행할 수있도록 했다. 예를 들어, 파일 입출력과 같은 작업은 kernel mode에서만 수행된다.
user mode인 프로세스가 입출력과 같은 작업을 실행하고 싶다면 제공되는 시스템 콜을 사용한다. 커널은 시스템 콜을 통하여 자신의 주요 기능을 사용자 프로그램에게 제공한다. 이러한 기능에는 파일 시스템 접근, 프로세스 생성 및 제거, 다른 프로세스와의 통신 및 메모리 할당 등이 포함된다.
시스템 콜을 실행하기 위해 프로그램은 trap이라는 특수 명령어를 실행해야 한다. 이 명령어는 커널 안으로 분기하는 동시에 kernel mode로 현재 특권 수준을 상향 조정한다. 이렇게 kernel mode로 진입하면 운영체제는 모든 명령어를 실행할 수 있고, 완료되면 return from trap 특수 명령어를 통해 다시 user mode로 특권 수준을 하향한다.
커널은 부팅 시에 트랩 테이블(trap table) 을 만들고 이를 이용하여 시스템을 통제한다. 운영체제가 하는 초기 작업 중 하나는 하드웨어에게 예외 사건이 일어났을 때 어떤 코드를 실행해야 하는지 알려주는 일이다. 예를 들어, 하드 디스크 인터럽트가 발생하면, 키보드 인터럽트가 발생하면, 또는 프로그램이 시스템 콜을 호출 하면 무슨 코드를 실행해야 하는지 알려준다. 운영체제는 특정 명령어를 사용하여 하드웨어에게 트랩 핸들러(trap handler)의 위치를 알려준다. 하드웨어는 이 정보를 전달받으면 해당 위치를 기억하고 있다. 따라서 시스템 콜과 같은 예외적인 사건이 발생했을 때 하드웨어는 무엇을 해야 할지 (즉, 어느 코드로 분기하여 실행할지) 알 수 있다.
운영체제에서 인터럽트는 하드웨어나 소프트웨어에서 발생하는 예기치 않은 이벤트를 의미합니다. 이벤트는 현재 실행 중인 프로그램의 흐름을 중단하고 운영체제에게 처리를 요청합니다. 인터럽트는 시스템의 일부분에 발생하는 중단 신호로 이해할 수 있습니다. 인터럽트는 여러 가지 상황에서 발생할 수 있습니다. 몇 가지 주요한 인터럽트 유형은 다음과 같습니다
하드웨어 인터럽트: 하드웨어 장치에서 발생하는 이벤트로, 예를 들어 타이머 인터럽트, 입출력 장치에서의 완료 신호, 하드웨어 오류 등이 있습니다. 소프트웨어 인터럽트: 프로그램 실행 중 명령에 의해 발생하는 이벤트로, 주로 시스템 콜이나 예외 상황에 의해 발생합니다.
3. 문제점 2: 프로세스 간 전환
운영체제는 실행 중인 프로세스를 계속 실행할 것인지, 멈추고 다른 프로세스를 실행할 것인지 결정해야 한다. 이는 까다로운 문제이다.
CPU에서 프로세스가 실행 중이라는 것은 운영체제는 실행중이지 않다는 것을 의미한다. 운영체제가 실행하고 있지 않다면 어떻게 이런 일들을 할 수 있을까?
협조 방식: 시스템 콜 기다리기
협조 방식은 일부 과거 시스템에서 사용된 방법으로, 운영체제가 프로세스들이 합리적으로 행동할 것이라고 가정한다. 프로세스들은 주기적으로 CPU 제어를 운영체제에게 양보해야 한다는 가정하에 동작한다. 주로 시스템 콜을 호출하여 CPU 제어를 운영체제에게 넘겨준다.
비협조 방식: 운영체제가 전권을 행사
프로세스가 협조하지 않거나 시스템 콜을 호출하지 않아 운영체제에게 제어를 넘기지 않을 경우, 운영체제는 추가적인 도움 없이 제어를 획득하기 어렵다. 이를 해결하기 위해 타이머 인터럽트 기능을 사용한다. 타이머 인터럽트는 정기적으로 발생하여 운영체제에게 CPU 제어를 양도합니다.
문맥 교환 (Context Switching)
문맥 교환은 프로세스 전환이 일어날 때 현재 실행 중인 프로세스의 상태를 저장하고 다음에 실행될 프로세스의 상태를 복원하는 과정이다. 문맥 교환은 운영체제의 스케줄러에 의해 결정된다. 레지스터 값과 스택 포인터 등의 상태를 저장하고 복원하여 제어를 전환다.
타이머 인터럽트와 문맥 교환
타이머 인터럽트는 정기적으로 발생하여 운영체제에게 CPU 제어를 양도하는 역할을 한다. 타이머 인터럽트가 발생하면 현재 실행 중인 프로세스의 레지스터 값을 저장하고, 다음에 실행될 프로세스의 레지스터 값을 복원한다. 이를 통해 운영체제는 다른 프로세스로 전환하여 실행을 계속할 수 있다.
4. Concurrency?
인터럽트 처리 중 다른 인터럽트가 발생하면 어떻게 할 것인지, 시스템 콜 처리 중 timer interrupt가 발생하면 어떤 것을 먼저 처리할지?
- Disable Interrupt -> 다른 인터럽트 처리 중일 때 발생하는 인터럽트 무시
- Priority -> 인터럽트에 우선순위를 두어 순차적으로 처리
- Locking Mechanism -> Lock 기법 사용
OSTEP 교재 참고