[OSTEP 가상화(virtualization)]Chapter 6 프로세스 실행

 

CPU를 가상화하기 위해서 운영체제는 여러 작업들이 동시에 실행되는 것처럼 보이도록 물리적 CPU를 공유합니다.

기본적인 아이디어는 간단합니다. 한 프로세스를 잠시동안 실행하고 다른 프로세스를 또 잠깐 실행하는 것입니다.

이러한 방식처럼 CPU 시간을 나누어 씀으로써 가상화를 구현할 수 있습니다.

 

그러나 가상화 기법을 구현하기 위해서는 몇가지 문제를 해결해야합니다. 첫 번째는 성능 저하입니다. 시스템에 과중한 오버헤드를 주지 않으면서 가상화를 구현해야합니다. 두 번째는 제어 문제입니다. CPU에 대한 통제를 유지하면서 프로세스를 효율적으로 실행시켜야 야합니다. 

 

핵심 질문
운영체제는 효율적인 방식으로 CPU를 가상화하지만 시스템에 대한 제어를 잃지 않는다. 제어를 잃지 않기 위해 하드웨어와 운영체제의 지원이 필수적입니다. 종종 운영체제는 작업을 효과적으로 수행하기 위해 하드웨어가 제공하는 기능을 사용합니다.

 

📝9.1 기본 원리 : 제한적 직접 실행

운영체제 개발자들은 프로그램을 빠르게 실행하기 위해 제한적 직접 실행이라는 기법을 개발하였습니다. 이 아이디어의 "직접 실행"에 해당하는 부분은 간단합니다. 프로그램을 CPU 상에서 그냥 직접 실행시키는 것이다. 따라서 운영체제가  프로그램을 실행하기 시작할 때 프로세스 목록에 해당 프로세스 항목을 만들고 메모리를 할당하여 프로그램 코드를 디스크에서 탑재하고 진입점을 찾아 그 지점으로 분기하여 사용자 코드를 실행한다.

 

 

해당 사진은 기본적인 직접 실행 프로토콜이다. 하지만 해당 방법은 CPU를 가상화함에 있어 몇가지 문제를 일으킨다.

첫 번째는 간단한 문제로 프로그램을 직접 실행시킨다면 프로그램이, 운영체제가 원치않는 일을 하지 않는다는 것을 보장할 수 없다. 두 번째 문제는 프로세스 실행 시, 운영체제는 어떻게 프로그램의 실행을 중단하고 프로세스로 전환할 수 있는가이다.

즉. CPU를 가상화하는 데 필요한 시분할 기법을 어덯게 구현하는가 이다.

 

📝9.2 문제점 1: 제한된 연산

직접 실행의 장점은 빠르게 실행된다는 것이다. 기본적으로 프로그램이 하드웨어 CPU에서 실행되기 때문이다.

그러나 CPU에서 직접 실행하면 문제점이 발생한다. 만일 프로세스가 특수한 종류의 연산을 수행하길 원한다면 어떻게 될것인가?이다. 이러한 연산에는 디스크 입출력 요청이나 CPU 또는 메모리와 같은 시스템 자원에 대한 추가할당 요청이 필요하다.

프로세스가 원하는 대로 할 수 있게 방치하는 방안이 있으나 바람직하지 않다. 

보호된 제어 양도

하드웨어는 두 가지 실행 모드를 제공하여 운영체제를 돕는다. 사용자 모드에서 응용 프로그램은 하드웨어 자원에 대한 일부 권한이 제한되어 있다. 컴퓨터 모든 자원에 대한 접근은 커널 모드에서 이루어진다.

이 때문에 사용자 모드로 알려진 새로운 모드가 도입되었다. 사용자 모드에서 실행되는 코드는 할 수 있는 일이 제한된다.

커널 모드는 사용자 모드와 대비되는 모드로 운영체제의 중요한 코드들이 실행된다. 

 

이러한 것으로 우리는 제한된 연산을 이루었지만 하나의 문제가 있다. 사용자 프로세스가 디스크 읽기와 같은 특권 명령어를 반드시 실행해야 할때는 어떻게 해야할까? 이런 제한 작업의 실행을 허용하기 위해 시스템 콜을 사용한다.

 

시스템 콜은 다른 공간에서 해당 명령을 처리하며 처리 완료 후 다시 사용자 프로세스로 돌아온다.

간단하게 정리하면

• trap: 사용자 모드에서 trap 시스템 콜을 사용하여 커널 모드의 기능을 사용할 수 있습니다.
• return-from-trap: trap을 사용한 명령이 완료되면 호출한 사용자 프로그램으로 돌아갑니다.
• 커널 스택(kernel stack): 프로그램 카운터, 플래그, 레지스터들을 각 프로세스의 커널스택에 저장하여 보관. return-from-trap 명령어가 커널 스택에서 값을 가져와서 사용자 프로그램의 다시 실행합니다.
• 트랩 테이블(trap table): 트랩 테이블은 트랩이 발생했을 때, CPU가 어디로 점프해야 할지에 대한 정보가 담긴 테이블입니다.
• 트랩 핸들러(grap handler): 트랩 핸들러는 시스템 콜을 처리하는 역할을 하며, 실제로 필요한 작업을 커널 모드에서 수행합니다.

trap 과정

1. 사용자 모드에서 trap 호출
2. 레지스터를 커널 스택에 저장
3. 하드웨어에서 트랩 테이블의 트랩 위치를 보고 트랩 핸들러로 분기
4. 커널 모드에서 트랩 처리
5. return-from-trap
6. 하드웨어가 커널 스택에서 데이터 복구
7. 사용자 모드로 전환

 

📝9.3 문제점 2: 프로세스 간 전환

직접 실행의 두 번째 문제점은 프로세스 간 전환을 할 수 있어야 한다는 점이다. 

프로세스 전환은 간단해보이지만 운영체제는 실행 중인 프로세스를 계획 실행할 것인지 멈추고 다른 프로세스를 실행할 것인지 결정해야 한다. 이것은 실제로 까다로운 문제이다. CPU에서 프로세스가 실행 중이라는 것은 운영체제는 실행 중이지 않다는 것을 의미한다. 운영체제가 실행하고 있지 않다면 어떻게 이런 일들이 가능할까? ( 사실 방법이 없다)

 

핵심 질문
운영체제는 어떻게 CPU를 다시 획득해서 프로세스를 전환할까?

협조 방식 : 시스템 콜 기다리기

협조 방식으로 알려진 방법은 과거의 몇몇 시스템에서 채택되었던 방법이다. 

이 방식은 운영체제가 프로세스들이 합리적으로 행동할 것을 가정한다. 너무 오랫동안 실행할 가능성 있는 프로세스는 운영체제가 다른 작업을 실행할 결정을 할 수 있도록 주기적으로 CPU를 포기한다고 가정하였다. 넘겨주는 방법은 시스템 콜을 호출하여 CPU의 제어권을 운영체제에 넘기는 것이다.

 

응용 프로그램이 비정상적인 행위를 하면 운영체제에게 제어가 넘어간다.  협조 방식은 스케줄링 시스템에서 운영체제는 시스템 콜이 호출되기를 기다리거나 불법적인 연산이 일어나면 CPU 제어권을 획득한다.

 

비협조 방식 : 운영체제가 전권을 행사

프로세스가 시스템 콜을 호출하기를 거부하거나 실수로 호출하지 않을 경우 운영체제가 할 수 있는 일이없다.

사실, 협조 방식에서 무한 루프에 빠졌을 경우 컴퓨터 부팅 밖에 해결 방법이 없다. 

 

그래서 협조 없이 제어를 얻는 방법을 고민하게 되었는데, 그 해결책은 의외로 간단하다. 그것은 타이머 인터럽트를 이용하는 것이다. 타이머 장치를 이용해서 정기적으로 인터럽트를 발생하는 것이다. 운영체제는 인터럽트가 발생하면 현재 수행 중인 프로세스를 중단하고 인터럽트 핸들러를 수행한다. 이 시점에서 운영체제는 CPU 제어권을 얻는다. 

 

인터럽트 발생 시 하드웨어는 실행 중이던 프로그램의 상태를 저장하여 나중에 return-from-trap 명령어가 프로그램을 다시 시작할수 있도록 한다. 

 

문맥의 저장과 복원

시스템 콜을 통하여 협조적으로 하던, 타이머 인터럽트를 사용하던 운영체제는 제어권을 다시 획득하면 중요한 결정을 내린다.

즉 현재 실행 중인 프로세스를 계속 실행할 것인지 아니면 다른 프로세스로 전환할 것인지 결정한다.

 

이 결정은 운영체제의 스케줄러라는 부분에 의해 내려진다.

다른 프로세스로 전환하기로 결정되면 운영체제는 문맥 교환이라고 알려진 코드를 실행한다.

1. 현재 실행 중인 프로세스의 레지스터 값을 커널 스택 같은 곳에 저장
2. 곧 실행될 프로세스의 커널 스택으로부터 레지스터 값을 복원

그림처럼 문맥 교환 중에는 두 번의 레지스터의 저장/복원이 일어난다. 

 

 

📝9.4 요약

우리는 CPU 가상화 구현을 위한 핵심적인 저수준 기법에 관해 알아보았다. 이러한 기법을 제한적 직접 실행이라 부른다.

• • 기본 아이디어: 실행하고 싶은 프로그램을 CPU에서 직접 실행.
  • 문제점 1: 프로세스 행동 신뢰 불가 → 해결책: 커널/사용자 모드로 민감 작업 제한.
  • 문제점 2: CPU 점유로 OS 실행 불가 → 해결책: 시스템 콜을 통한 협조적 방식 or 타이머 인터럽트를 통한 비협조적 방식으로 제어권 획득.