[OSTEP 가상화(virtualization)]페이징: 개요

📝서론 

운영체제는 거의 모든 공간 관리 문제를 해결할 때 두 가지 중 하나를 사용한다.

1. 가변 크기의 조각들로 분할하는 것(세그먼테이션)
   • 가변 크기로 분할하게 되면 공간 자체의 단편화가 발생
   • 메모리 할당이 점점 어려워진다.
2. 동일 크기의 조각들로 분할하는 것(페이징)
   • 유연성 개선 : 프로세스의 주소 공간 사용방식과는 상관없이 효율적인 주소 공간 개념 지원
   • 빈 공간 관리의 단순함
     • 운영체제는 모든 비어있는 페이지의 빈 공간 리스트만 유지하면 된다.
     • 운영체제는 페이지 테이블을 프로세스마다 유지 

📝간단한 예제 및 개요

페이징에 대해 명확히 이해하기 위해 간단한 예를 살펴보자

아래 그림은 가상 메모리를 작은 단위로 쪼개서 페이지라 부르며 아래와 같이 구성된다. 

 

 

물리 메모리는 아래 그림과 같이 고정 크기의 슬롯들로 이루어진다.

물리 메모리는 페이지 프레임이라는 똑같은 크기의 슬롯으로 나눈다.

이 경우 8개의 페이지 프레임, 총 128바이트의 비현실적으로 작은 물리 메모리이다. 

운영체제는 가상페이지 물리페이지 프레임을 연결해주는 페이지 테이블을 사용한다. 

그렇기에 다른 주소 공간 개념에서도 효율적으로 지원이 가능하다. 

 

또다른 장점은 페이징이 제공하는 빈 공간 관리의 단순함이다. 

주소 공간을 할당하기 위해 빈 공간 리스트에서 찾기만 하면 되기 때문이다. 

 

주소 공간의 각 가상 페이지에 대한 물리 메모리 기록을 위한 운영체제 프로세스 마다 페이지 테이블이라는 자료 구조를 유지한다.

페이징 테이블의 역할은 주소 공간의 가상 페이지 주소 변환 정보를 저장하는 것이다.

 

프로세스가 생성한 가상 주소의 변환을 위해 먼저 가상 주소를 가상 페이지 번호(VPN)와 페이지 내의 오프셋 2개의 구성 요소로 분할한다.

 

가상주소 = VPN + Offset

64바이트의 물리 주소를 가질때 16바이트로 페이지의 크기를 나누면 6비트를 사용해서 물리 주소를 나타낼 수 있다. 앞의 2비트는 VPN으로 가상 페이지 번호를 가지고 잇고 offset은 해당 페이지 번호에서 특정하고 있는 바이트의 위치를 나타낸다. offset은 각 페이지의 모든 바이트를 지정할 수 있어야하기 때문에 최댓값이 페이지의 크기-1을 가진다.

 

 

VPN을 사용해서 해당 페이지의 물리 주소를 찾아 낼 수 있다. Offset은 가상 페이지와 물리 주소상에서 동일하기 때문에 변환하지 않는다. 

 

 

📝21.2 페이지 테이블은 어디에 저장되는가

페이지 테이블은 매우 커질 수 있다. 우리가 이전에 논의했던 작은 세그먼트 테이블이나 베이스-바운드 쌍에 비하면 말이다. 

20비트 VPN은 운영체제가 각 프로세스를 관리해야 하는 변환의 개수는 20의 20승이다. 물리 주소로의 변환 정보와 다른 필요 정보를 저장하기 위해 페이지 테이블 항목(PTE) 마다 4바이트가 필요하면 매우 커진다.

 

이렇게 페이지 테이블이 매우 크기에 현재 실행 중인 프로세스의 페이지 테이블을 저장하는 회로를 MMU 안에 유지하지 않는다.

대신 각 프로세스의 페이지 테이블을 메모리에 저장한다. 

 

📝21.3 페이지 테이블에는 실제 무엇이 있는가

선형 페이지 테이블

단순한 배열 형태, 원하는 물리 프레임 번호를 찾기 위하여 가상 페이지 번호로 배열의 항목에 접근한다.

그 항목을 통해 페이지 테이블을 검색한다. 

 

📝21.4 페이징 : 너무 느림

페이지 테이블의 크기가 메모리 상에서 매우 크게 증가할 수 있다. 페이지 테이블로 인해 처리 속도가 저하될 수 있다는 것이다.

 

예를 들어 단순한 명령어가 들어오면 이것 또한 페이지 테이블을 거친다.

이러한 간단한 명령어도 실제로는 다음 단계를 거친다.

 

1. 가상 주소 → 물리 주소 변환 필요
2. 변환을 위해 페이지 테이블 항목(PTE)에 접근
3. 해당 페이지가 유효한지 검사
4. 물리 주소 계산
5. 실제 메모리 접근

즉, 하나의 메모리 접근을 위해 최소 2번의 메모리 접근이 필요해져 → 엄청 느려짐!

그렇기에 명령어마다 페이지 테이블에 접근해야 하므로 오버헤드가 매우 크다.

 

예를 통해 들어나는 문제점들

1. 느려짐 (성능 문제)

• 매 메모리 접근마다 추가적인 메모리 접근이 필요함 (PTE 가져오기 위해)
• → 메모리 접근 횟수가 2배 이상, 프로그램 속도 저하

2. 메모리 낭비 (공간 문제)

• 각 프로세스마다 큰 페이지 테이블이 필요
• 특히 32비트/64비트 가상 주소 공간에선 페이지 수가 엄청나게 많음
• → 페이지 테이블이 차지하는 메모리 너무 큼

 

다음 장에서 알아보겠지만 해결책으로 아래 방식들이 있다.

 

• ✅ TLB (Translation Lookaside Buffer)
  → 페이지 테이블을 매번 접근하지 않게 하기 위해 최근 변환 캐시
• ✅ 다단계 페이지 테이블 (Multilevel Paging)
  → 실제 필요한 부분만 메모리에 올려 메모리 절약
• ✅ 인버티드 페이지 테이블 (Inverted Page Table)
  → 페이지 수가 아닌 프레임 수 기반 테이블로 공간 줄임

 

 

📝요약

🔸 1. 페이징이란?

• 가상 메모리 공간을 고정된 크기의 블록(페이지)로 나눔
• 물리 메모리는 같은 크기의 페이지 프레임으로 나눔
• 운영체제가 각 프로세스마다 페이지 테이블을 통해 가상페이지 ↔ 물리프레임 매핑 관리

---

🔸 2. 페이징의 장점

• ✔ 단편화 문제 완화: 가변 크기 세그먼테이션과 다르게, 고정 크기이므로 외부 단편화가 없음
• ✔ 공간 관리 단순화: 비어 있는 프레임 리스트만 유지하면 됨
• ✔ 주소 공간 유연성: 프로그램 구조와 무관하게 메모리 배치 가능

---

🔸 3. 주소 변환 과정

• 가상주소 = VPN (가상 페이지 번호) + offset
• VPN → PTE(Page Table Entry) → PFN(물리 프레임 번호)
• 최종 주소 = PFN << shift | offset

---

🔸 4. 페이지 테이블 문제점

1. 느림 (성능 문제)
   • 모든 메모리 접근마다 PTE를 먼저 읽기 → 메모리 접근이 최소 2번
   • 캐시 미스 시 더 느림
2. 메모리 낭비 (공간 문제)
   • 페이지 테이블이 프로세스마다 매우 큼
   • 예: 32비트 주소 공간 → 수백~수천 MB 차지 가능