CPU와 마찬가지로 메모리를 가상화하는 이유는 각 프로그램이 private 메모리를 갖고 있게끔 착각을 주기 위해서이다.
메모리 가상화는 어떤 방식으로 이루어지고, 또 어떤 기술이 필요할까? 이제부터 알아보도록 하자.
예시를 들기 전에, 말도 안되지만 몇가지 가정을 둘것이다.
1. address space는 physical memory에 연속적으로 존재한다.
2. address space의 크기는 physical memory보다 작다.
3. 각 address space의 크기는 동일하다.
위의 코드를 시킨다면 컴파일러는 아래와 같이 어셈블리어로 전환 할 것이다.
코드는 매우 단순하다. 변수 x는 레지스터 ebx에 존재하고, ebx의 값을 레지스터 eax로 load한다.
eax에 3을 더한 후, 결과 값을 ebx로 다시 옮기는 코드이다.
이를 프로세스의 address space 관점에서 보면 어떻게 실행될까?
세가지의 instruction이 주소 128부터 위치해 있고, 변수 x는 주소 15KB에 위치해 있다.
프로그램이 실행된다면 다음과 같이 진행될 것이다.
1. 주소 128에 있는 instruction을 fetch한다.
2. instruction을 실행한다.(주소 15KB를 load한다.)
3. 주소 132에 있는 instruction을 fetch한다.
4. instruction을 실행한다.(메모리 참조는 없다.)
5. 주소 135에 있는 instruction을 fetch한다.
6. instruction을 실행한다.(주소 15KB에 store한다.)
프로그램의 관점에서 보면, address space는 주소 0부터 시작되어 16KB까지 차지한다.
하지만 OS는 실제로 프로세스를 주소0이 아닌 다른 곳에 위치시키고 싶을 수 있다.
그럼 프로세스에 transparent하게 프로세스 메모리를 relocate시킬 수 있을까? 즉, 어떻게 address space가 실제로 다른 곳에 위치하지만 주소 0에서 시작되는 것 같은 착각을 줄 수 있을까?
Dynamic Relocation (Hardware-based)
처음 time sharing을 도입한 머신에서는 base and bound라고 불리는 기술을 고안했다.
(또는 dynamic relocation이라고 불린다.)
이를 위해 CPU 내에는 base레지스터, bounds레지스터라고 불리는 두개의 레지스터가 필요하다. base, bounds 레지스터 쌍으로 address space를 다른 위치의 physical memory에 두는 것이 가능하다.
우선, 각 프로그램은 주소 0에 위치해 있는것 같이 작성되고 컴파일된다.
하지만 프로그램이 실행될때, OS는 프로세스를 load할 physical memory 주소를 결정하고, 그 값을 base register에 저장한다.
프로세스가 실행되며 메모리를 참조해야할 상황이 발생할 때, 메모리 주소는 다음과 같은 방식으로 translate된다.
프로세스에 의해 생성된 메모리 주소는 virtual address라고 불린다. 하드웨어가 base register의 값을 virtual address에 더한 결과가 physical address이다.
간단한 예를 들어 보겠다. 위의 instruction을 실행할 때 program counter(PC)는 instruction이 있는 주소인 128값을 가지고 있어야 한다. 하드웨어가 pc를 확인하여 instruction을 fetch할때, base register값인 32KB(32768)을 virtual address값인 128에 더해 physical address에 해당하는 주소32896에서 instruction을 fetch한다.
이렇게 virtual address를 physical address로 변환하는 기술을 address translation이라고 한다.
주소를 relocation하는 것이 런타임에서 발생하기 때문에 이 기술을 dynamic relocation이라고 부르기도 한다.
앞서 분명히 base and bound라고 했다. bound레지스터는 어디에 사용하는 것일까?
bound 레지스터는 protection에 아주 중요한 역할을 한다.
특히, 프로세스는 address translation 이후 계산된 physical address가 실제 주소의 경계값 안에 포함 되는지 검증을 한다.
그러므로 bounds는 프로세스에 의해 생성된 주소가 프로세스의 bounds 내에 속하는지 보장하는 역할을 한다.
bound 레지스터는 두가지 방식이 있는데, address space의 크기를 저장하는 방식, address space의 끝의 physical memory를 저장하는 방식이 있다.
base, bounds 레지스터는 CPU에 있는 하드웨어 구조물이다. 이런 address translation을 돕는 파트를 memory management unit(MMU)라고도 부른다.
Hardware Support
메모리 virtualization을 위해 필요한 하드웨어 지원에 대해 정리해보자.
• Privileged mode
프로세스 마다 address space 주소가 다르기 때문에, base register과 bounds register을 수정해주어야 한다.
이때, 수정에 관한 instruction은 privileged해야 한다. 즉, kernel mode에서 실행되어야 한다.
• Base/bounds registers
CPU마다 address translation을 위해 base, bounds register가 필요하다.
• Ability to translate virtual addresses and check if within bounds
• Privileged instruction to update base/bounds
• Privileged instruction to register exception handlers
• Ablity to raise exceptions
프로그램이 불법적으로 "out of bounds"에 해당하는 메모리 주소에 접근하려고 할 때 exception을 발생시켜야 한다.
Operation System Issue
OS 또한 dynamic relocation을 위해 몇가지 기능을 제공해야한다.
• Memory management
OS는 프로세스가 생성되었을때 메모리에 있는 address space를 찾아 할당해야 한다.
이때, free list라고 불리는 데이터 구조를 수색하여 비어 있는 주소를 찾아 할당한다. (위의 사진에서는 16KB-32KB, 48KB-64KB가 비어있다.) 그리고 프로세스가 종료되었을때, 할당 되었던 메모리 주소를 free list에 다시 저장해야 한다.
• Base/bounds management
프로세스마다 프로그램이 load되어 있는 메모리의 physical address가 다르기 때문에, context switch가 발생했을때, OS는 base-and-bounds 레지스터를 save하고 restore해야한다. 이때, 멈추는 프로세스의 base, bounds 레지스터 값을 Process control block(PCB)와 같은 프로세스 자료 구조에 저장한다.
•Exception handling
예를 들어, 프로세스가 out of bound 메모리 주소에 접근하여 CPU에서 exception을 발생시켰을때 OS는 해당 exception을 처리할 handler를 제공해야 한다.
요약
이 장에서는 가상 메모리에서 사용되는 특정 메커니즘인 address translation을 통해 limited direct execution의 개념을 확장했다. address translation을 통해, OS는 프로세스의 모든 메모리 접근을 제어하여 접근이 주소 공간의 경계 내에서 이루어지도록 보장할 수 있다. 이 기술의 핵심은 하드웨어 지원에 있다. 하드웨어는 virtual address(프로세스의 메모리 관점)를 physical address(물리적 메모리 관점)로 변환한다. 이 모든 과정은 프로세스에 transparent하게 수행되기 때문에, 프로세스는 자신의 메모리 참조가 변환되고 있다는 사실을 전혀 알지 못하며, 이는 멋진 착시를 만들어낸다.
'운영체제 > Operating Systems in Three Easy Pieces' 카테고리의 다른 글
12. Virtualization) Free-Space (0) | 2024.09.26 |
---|---|
11. Virtualization) Segmentation (1) | 2024.09.19 |
9. Virtualization) Address Spaces (0) | 2024.04.07 |
8. Virtualization) Multi-CPU Scheduling (1) | 2024.03.19 |
7. Virtualization) Lottery Scheduling (0) | 2024.03.12 |