[운영체제] Memory - Paging

전윤혁·2024년 12월 9일
0

OS

목록 보기
9/18

이전 글까지 Segment를 통한 메모리 관리를 알아봤고, 그 과정에서 Internal Fragmentation, External Fragmentation 문제에 대해 알 수 있었다. 이번 글부터 알아볼 Paging은, 물리 메모리를 고정 크기로 나누는 방식이다.

물리 메모리를 고정 크기로 나누면 Segment와 달리 External Fragmentation 문제는 발생하지 않는다. 하지만, 애초에 Segment는 Internal Fragmentation 문제를 해결하기 위해 메모리를 Segment 단위로 나눈 것이기에, 다시 원점으로 돌아가는 느낌이다.

결국, 메모리 관리 방식에서 Internal Fragmentation과 External Fragmentation 문제는 상충관계에 있으며, 이를 완벽하게 해결할 수 있는 단일한 해결책은 존재하지 않는다. 그러므로 각 방식의 장단점을 파악하고, 혼합하는 방식으로 메모리 관리 문제를 해결하는 것이 중요하다.


1. Paging 개념

그렇다면 지금부터 Paging이 정확히 무엇인지 알아보자.

쉽게 설명하면, Paging은 주소 공간을 고정 크기의 단위인 페이지(page)로 분할하는 방식이다. 또한, 페이지와 일대일 대응되는 물리 메모리 상의 공간은 페이지 프레임(Page Frame) 이라고 한다.

위 그림은 전체 크기가 64B인 메모리 공간을 16B 크기의 페이지로 분할한 가상 주소 공간이다.

위의 가상 주소 공간에 대응되는 실제 물리 메모리는 위와 같은 형식으로 표현된다. 현재 물리 메모리의 상태를 아래와 같이 요약할 수 있다.

  • 0 ~ 16KB
    OS 할당
  • 16 ~ 32KB, 64 ~ 80KB, 96 ~ 112KB
    사용되지 않음
  • 32 ~ 48KB, 48 ~ 64KB, 80 ~ 96KB, 112 ~ 128KB
    AS에 할당 (예시의 가상 주소 공간)

여기서 Paging의 장점을 느낄 수 있다. Segmentation은 메모리 할당을 코드, 힙, 스택, 데이터와 같이 나눴지만, Paging은 단순히 고정 크기의 페이지를 할당하기 때문에 메모리 관리가 단순해진다. 또한, Splitting, Coalescing, Free Space Management 등을 신경 쓸 필요도 없어진다.


2. Paging 주소 변환

1) VPN & PFN 주소 변환

Base and Bounds에서는 Base, Bound Register를 사용하여 주소 변환을 진행할 수 있었고, Segmenation에서는 Segment 비트를 통해 각 Segment를 구분, Offset을 통해 Base 기준으로 주소 공간의 위치를 알 수 있었다.

Paging에서는 프로세스마다 페이지 테이블(Page Table)을 사용하여 주소 변환을 수행한다. 이전 방식과의 차이점은, 테이블을 사용하기 때문에 수식을 통한 변환이 아니라는 점이다. 단순히 Page Table에 저장되어 있는 가상 주소, 실제 주소의 매핑을 통해 주소 변환을 진행하게 된다.

가상 주소 Virtual Address는 VPN(Virtual Page Number)과 Offset으로 분할된다. 아래는 가상 주소 21의 실제 표현 예시이다.

여기서 VPN은 각각의 페이지를 의미하고, Offset은 각각의 페이지 내의 메모리 주소를 표현한다. 위의 예시에서는 64B의 메모리 공간을 페이지로 나눈 예시이다.

페이지의 개수가 22=42^2=4개이므로, 2개의 비트로 페이지를 표현하고, 각각의 페이지는 16B이므로, 4개의 Offset 비트를 통해 각 페이지에서의 주소를 표현한다. 만약 페이지의 개수를 8개로 나눴다면? VPN 3비트, Offset 3비트로 나눠질 것이다.

이 때, Page Table을 통해 단순히 VPN을 PFN(Physical Frame Number)으로 바꾸는 방식으로 가상 주소 -> 물리 주소 변환을 진행하게 된다. 아래의 그림을 보자.

결과적으로, 가상 주소는 111 번호가 가리키는 물리 메모리 프레임에서 Offset의 크기인 5B만큼 떨어진 위치를 가리키게 된다.

2) Page Table 저장 위치

지금까지는 CPU 내부에 존재하는 MMU(Memory Management Unit)에서 주소 변환을 처리한다고 배웠다. 하지만 Page 방식의 경우, 모든 프로세스의 주소 공간 연결 정보를 저장해야 하기 때문에, 그러한 정보를 CPU 내부에 넣기에는 크기가 너무 크다.

따라서, 자세한 부분은 이후에 설명하되, 우선 Page Table의 저장 위치는 MMU가 아니라 물리 메모리라고 생각하고 넘어가자!

3) Page Table의 구조

Page Table은 단순히 가상 주소를 물리 주소로 매핑하기 위해 사용되는 데이터 구조이고, 가장 간단한 형태로 Linear Page Table로 구현될 수 있다.

PTE(Page Table Entry)는 페이지 테이블 내에 있는 각각의 항목으로, 특정 가상 페이지가 매핑된 물리 주소와 관련된 정보를 포함한다. 아래는 x86 운영체제의 Page Entry 예시이다.

Page Table Entry의 각각의 비트의 위치나 역할을 외울 필요까지는 없지만, 주요 비트의 역할을 간단히 아래와 같이 요약할 수 있다.

  • Valid Bit
    해당 변환이 유효한지(실제 사용되는 공간인지) 여부
  • Protection Bit
    페이지가 읽기, 쓰기 또는 실행 가능한지 여부
  • Present Bit
    페이지가 메모리, 또는 디스크(Swap Out)에 있는지 여부
  • Dirty Bit
    페이지가 메모리에 들어온 후 수정되었는지 여부
  • Reference Bit (Accessed Bit)
    페이지가 접근되었는지 여부 (Swap에 사용)

Swap은 시스템 메모리가 부족할 때 사용하지 않는 데이터를 디스크의 스왑 영역으로 옮겨 물리적 메모리를 확보하는 과정이다. 유한한 메모리 공간을 사용하고 싶어하는 프로세스가 많기 때문에, 시스템은 자주 사용되지 않는 페이지를 디스크로 이동시키고, 필요할 때 다시 불러오게 된다. Swap은 뒤에서 구체적으로 알아보자!


3. Paging의 문제점

페이징의 장점은 Segment와 달리 힙과 스택의 성장 방식을 미리 예측할 필요가 없어 메모리 할당과 관리가 단순해지고, External Fragment 문제가 사라진다는 점이다. (물론, 고정된 페이지 크기에 따른 Internal Fragmentation 문제가 생기게 된다.)

하지만 페이징의 단점은 페이지 테이블을 통해 가상 주소를 물리 주소로 변환하기 때문에, 주소 변환 과정에서 추가적인 오버헤드가 발생할 수 있고, 페이지 테이블이 커질 경우 메모리 공간을 많이 차지할 수 있다는 점이다.

앞선 설명에서, Page Table은 크기가 너무 크기 때문에 CPU 내부에 정보를 저장할 수 없다고 설명했다. 따라서 Page Table에 접근하기 위해 물리 메모리(RAM)에 접근이 필요하며, 이 과정에서 오버헤드가 발생하는 것이다.


마치며

이번 글에서는 Paging에 대한 기본적인 내용을 알아본 후, Paging의 문제점에 대해서도 알아봤다.

다음 글에서는 이러한 Paging의 문제점을 완화하는 TLB(Translation Lookaside Buffer) 캐싱 기법과, Paging에 대한 추가적인 내용들에 대해 다뤄보도록 하겠다.

profile
전공/개발 지식 정리

0개의 댓글