[페이징 메모리 관리]

페이징

운영체제의 메모리 관리 기법 중 하나로, 프로세스의 메모리를 고정된 크기의 페이지(Page) 단위로 나누고, 물리 메모리(램) 역시 같은 크기의 프레임(Frame) 단위로 나누어 논리 주소를 물리 주소로 매핑하는 방식

 

핵심 개념

- 페이지 : 프로세스의 가상 주소 공간을 일정 크기로 나눈 단위

- 프레임 : 물리 메모리를 같은 크기로 나눈 단위

- 페이지 테이블 : 페이지 번호를 해당하는 프레임 번호로 변환할 때 사용되는 서로를 매핑시킨 테이블

 

프로세스의 주소 공간과 물리 메모리를 페이지 단위로 분할하고, 프로세스의 각 페이지를 물리 메모리의

프레임에 분산 할당하여 관리하는 기법

 

- 프로세스마다 페이지 테이블이 있다.

- MMU에 의해 논리 주소가 물리 주소로 변환된다.

- 내부 단편화가 발생 할 수 있다. --> 근데 미미한 정도라서 차라리 내부 단편화가 낫다.

- 외부 단편화를 줄일 수 있다.

- 메모리 활용과 시간 오버헤드면에서 우수 ---> 홀 선택 알고리즘을 수행할 필요가 없다. 어차피 같은 크기라서 아무데나 넣어도 된다.

 

페이징의 논리주소

페이지 번호 + OFFSET 으로 되어있다.

 

• 페이지 번호(Page Number, p):
  가상 주소 공간에서 어떤 페이지인지 식별하기 위한 번호이다.
  이 번호는 페이지 테이블에서 해당 페이지가 매핑된 프레임을 찾는 데 사용된다.
• 페이지 오프셋(Page Offset, d):
  해당 페이지 **내에서의 위치(주소)**를 나타낸다.
  즉, 페이지 안에서 몇 번째 바이트인지를 알려줌

예시:

가상 주소 공간: 16비트
페이지 크기: 4KB (즉, 2¹² = 4096바이트)

→ 그러면:

• 페이지 번호는 상위 4비트 (16 - 12 = 4비트)
• 페이지 오프셋은 하위 12비트

 

논리 주소 (16비트) = [페이지 번호 (4비트)] [오프셋 (12비트)]

 

 

 

페이지 테이블은 메모리 안에 있는데 그 페이지 테이블의 위치를 담고 있는 레지스터를 PTBR(Page Table Base Register)라고 한다.

 

 

페이지 테이블의 문제점

1. 1번에 메모리 엑세스를 위해서는 2번의 물리 메모리 엑세스가 필요하다. (시간)

페이지 테이블은 크기가 커서 캐시 메모리에는 담아 둘 수 없어서 메모리에 저장한다.

근데 CPU가 메모리를 엑세스 할때 마다, 2번의 물리 메모리의 엑세스가 필요하게 되는 문제점이 발생

(페이지 테이블 읽기) + (데이터 엑세스를 위한 1 번)

 

TLB 사용으로 문제 해결 (캐시에 저장)

 

TLB -> 논리 주소를 물리 주소로 바꾸는 과정에서 페이지 테이블을 읽어오는 시간을 없애거나 줄이는 방법

(주소 변환 캐시라고도 불림)

- 최근에 접근한 페이지 번호와 프레임 번호의 쌍을 항목으로 저장하는 캐시 메모리 (MMU에 존재)

 

[페이지 번호 P, 프레임 번호 F] 구조로 저장한다.

 

<TLB를 활용한 메모리 엑세스 과정>

1. CPU로부터 논리 주소 발생

2. 논리 주소의 페이지 번호가 TLB로 전달

3. 페이지 번호와 TLB내 모든 항목을 비교

- 페이지 번호가 있는 경우 HIT

- 페이지 없으면 MISS , 페이지 테이블로부터 프레임 번호를 읽어와 물리 주소 완성 후 

TLB에 삽입

 

TLB 는 참조 지역성으로 인하여 좋은 전략이 될 수 있다.

순차 메모리 기법을 사용할 시 TLB 히트가 결과적으로 계속되어 메모리의 페이지 테이블 접근이 불필요

하지만 랜덤 메모리 엑세스라면 미스가 자주 발생하여 느림.

 

* 동일한 프로세스 내에서는 다른 스레드로 스위칭 되는 경우 TLB항목들이 교체될 필요가 없다

(동일한 프로세스 주소공간에서 실행되므로 동일한 프로세스 테이블을 사용)

 

다른 프로세스의 스레드로 스위칭 되는경우

1. CPU의 모든 레지스터를 TCB에 저장

2. 새프로세스의 PCB에 저장된 페이지테이블주소를 CPU의 PTBR에 적재

3. TLB의 모든 항목 지우기

4. 새로 스케줄된 스레드의 TCB에서 레즈스터 값을 적재

 

 

2. 페이지 테이블의 낭비 (공간)

프로세스의 실제 크기는 매우 작아서 대부분의 페이지 테이블 항목이 비어 있는 문제가 발생한다.

단순 페이징 구조에서는 프로세스의 가상 주소 공간 전체(예: 4GB 등)를 페이지 크기로 나눠서,

모든 페이지에 대응하는 항목을 페이지 테이블에 만들어 놓기 때문에 낭비가 심하다.

 

(페이지 테이블은 프로세스의 최대 크기를 기준으로 생성된다.) --> 하지만 현대에서는 여러가지 낭비를 

줄이는 방법이 많이 사용된다.

 

멀티레벨 페이지 테이블 등을 통해 해결한다.

 

예를들어 32비트 환경이라면 프로세스의 주소공간은 4GB이고 약 100만개의 페이지로 구성된다. (페이지당 4KB)

한 항목이 4바이트면 프로세스당 페이지 테이블의 크기는 4MB가 된다.

하지만 실제로는 10MB의 메모리만을 실질적으로 사용한다면 실제 활용되는 페이지 테이블 항목수는 2560밖에 없다.

 

해결책

1. 역 페이지 테이블

2. 멀티 레벨 페이지 테이블

 

1. 역페이지 테이블 (Inverted Page Table = IPT)

이것은 기존에 페이지에 대해서 물리주소를 매핑한 개념과는 반대로 물리주소에 대하여 어떤 페이지가 매핑되어 있는지에 대한 것이다.

시스템에 1개의 역 페이지 테이블을 둔다. (역 페이지 테이블 항목수 = 물리 메모리의 프레임 갯수)

프레임번호를 통해서 인덱스를 생성한다.

 

주소 변환

1. CPU가 가상 주소(Virtual Address)를 생성
   예: VPN = 5, offset = 0x30
2. IPT를 통해 (VPN + PID)를 검색
   → 해시 테이블 등을 사용하여 IPT 전체에서 해당 항목을 찾음
3. IPT에서 해당 항목의 PFN(물리 프레임 번호)를 가져옴
4. PFN + offset을 합쳐서 최종 물리 주소를 얻음

* 시스템 전체에서 페이지 테이블 하나만 유지하기에 멀티 프로세스가 많은 환경에서 유리하다.

 

* 역페이지테이블 항목수 = 물리메모리크기/프레임크기

물리메모리가 4GB 프레임크기가 4KB면 4GB/4KB = 2의20승 = 약 100만개

 

* 역페이지 테이빌크기는 컴퓨터에 설치된 물리 메모리 크기에 따라 달라진다.

물리 메모리가 4GB, 프레임 크기가 4KB, 한 항목크기가 8바이트라면

역페이지테이블의 크기는 2의 20승 X 8바이트 = 8MB이다.

 

정리 :

기존 방식의 비효율 (문제점 정리)

일반 페이지 테이블 구조 (Per-process Page Table):

• 프로세스 하나마다 자기만의 가상 주소 공간 (보통 4GB)
• 이 공간을 4KB 페이지 단위로 나누면 → 2²⁰ = 약 100만 개 페이지
• 페이지당 4바이트 PTE면 → 프로세스당 4MB 페이지 테이블
• 10개 프로세스면 = 40MB 필요 (많은 공간 낭비)

문제: 가상 주소 공간이 클수록, 실제 메모리를 얼마나 쓰든 간에 전체 페이지 테이블 크기는 고정적으로 큼

 

역페이지 테이블은 “필요한 만큼만”, 그리고 “전체 시스템 기준으로” 관리함. ( 역페이지 테이블은 물리 프레임 수만큼만 엔트리 필요함 )

 

역페이지 테이블의 단점 : 

검색 속도가 느리기에 TLB가 필수이다.

IPT는 시스템 전체에 하나밖에 없기 때문에, 멀티프로세스가 동시에 접근하면 동시성 문제가 생길 수 있어서 멀트프로세스 병렬 처리가 어렵다.

 

 

2. 멀티레벨 페이지 테이블 

프로세스가 현재 사용중인 페이지들에 대해서만 페이지 테이블을 만드는 형식

대부분의 현대 운영체제 (리눅스, 윈도우 등)에서 쓰는 방식

 

논리 주소 구성 : [페이지 디렉터리 인덱스] , 페이지 테이블 인덱스, 옵셋 ]

 

32비트 환경에서 예로 들자면 아래와 같이 구성된다.

페이지 디렉터리 인덱스 (10비트)

페이지 테이블 인덱스 (10비트)

오프셋 (12비트)

 

 

 

 

기존에는 전체 프로세스 주소 공간에 대해서 하나의 페이지 테이블을 생성했지만 

이제는 데이터 하나에 대한 주소값 논리구조가 상위비트(10비트) + 중간비트(10비트) + 오프셋 (12비트) = 총 32비트

로 변했으므로 이것에 맞춰 1024개의 페이지를 하나의 단위로 나누면 총 1024개의 묶음이 나오는 것이다.

1024 * 1024 = 100만 (2의 20승 --> 기존 상위비트 및 페이지 총 갯수) 

 

사용하지 않는 부분에 대해서는 페이지 테이블을 만들지 않는다.