Page table과 TLB로 이해하는 OS memory 관리

프로그램에서 pointer 값을 출력하면 마치 실제 memory 주소를 직접 보는 것처럼 느껴질 때가 있습니다.

하지만 현대 운영체제에서 application이 보는 주소는 대부분 Virtual address입니다.

실제 Physical memory의 어느 위치를 쓰는지는 MMU, Page table, 운영체제 memory manager가 함께 결정합니다.

 

Virtual memory는 Process가 독립된 address space를 가진 것처럼 보이게 만드는 모델이고, Page fault는 필요한 page가 현재 Physical memory에 없을 때 운영체제가 개입하는 사건입니다.

 

이번 글에서는 Virtual memory, Page table, Page fault, TLB가 각각 어떤 역할을 하는지, 그리고 C++ 코드에서 memory 접근 패턴을 볼 때 왜 이 개념이 필요한지 정리해보겠습니다.

 

Virtual memory는 Process가 보는 address space와 실제 Physical memory 사이에 address translation 계층을 둡니다.

 

---

1. Virtual memory는 무엇인가?

Virtual memory는 각 Process가 자신만의 연속적인 address space를 가진 것처럼 보이게 만드는 운영체제와 hardware의 메모리 관리 방식입니다.

Process는 Virtual address를 사용해 instruction과 data에 접근합니다.

CPU와 MMU는 이 Virtual address를 Physical address로 변환하고, 운영체제는 어떤 Virtual page가 어떤 Physical frame에 연결되는지 관리합니다.

이 구조 덕분에 서로 다른 Process가 같은 주소값을 쓰는 것처럼 보여도 실제 memory는 분리될 수 있습니다.

또한 운영체제는 필요한 page만 Physical memory에 올리고, 당장 쓰지 않는 page는 disk나 backing store로 내보낼 수 있습니다.

 

개념	의미	실무에서 연결되는 지점
Virtual address	Process가 사용하는 주소	pointer 출력값, debugger의 address
Physical address	실제 RAM 위치를 가리키는 주소	운영체제와 hardware가 관리
Page	Virtual memory를 나누는 고정 크기 단위	allocation, page fault, memory mapping
Frame	Physical memory를 나누는 고정 크기 단위	page가 실제로 올라가는 공간
Page table	Virtual page와 Physical frame의 매핑 정보	address translation 비용과 protection

중요한 점은 Virtual memory가 단순히 memory를 크게 보이게 하는 기술만은 아니라는 것입니다.

Process isolation, memory protection, lazy allocation, memory mapped file, shared library, copy-on-write 같은 기능도 이 모델 위에서 자연스럽게 구현됩니다.

 

---

2. 왜 중요한가?

Virtual memory를 이해하지 못하면 memory 문제를 너무 단순하게 해석하기 쉽습니다.

예를 들어 Process의 address space가 크다고 해서 그만큼 RAM을 즉시 사용한다는 뜻은 아닙니다.

반대로 실제 working set이 Physical memory보다 커지면 Page fault가 늘고, latency가 갑자기 커질 수 있습니다.

1. 큰 address range를 예약해도 실제 page는 접근할 때 할당될 수 있습니다.
2. 같은 pointer 값처럼 보여도 Process가 다르면 다른 Physical memory를 가리킬 수 있습니다.
3. memory 접근 패턴이 나쁘면 CPU cache뿐 아니라 TLB 효율도 떨어질 수 있습니다.
4. Page fault가 disk IO로 이어지면 단순 memory access가 매우 느린 작업이 될 수 있습니다.
5. container growth, memory mapped file, large allocation을 볼 때 page 단위 동작을 함께 생각해야 합니다.

기술 면접에서도 이 주제는 단순 암기보다 연결 설명이 중요합니다.

좋은 답변은 “Virtual memory는 실제 memory보다 크게 보이게 한다”에서 끝나지 않습니다.

주소 변환, Page table, Page fault, TLB, Process isolation까지 이어서 설명할 수 있어야 합니다.

 

---

3. 핵심 개념은 Page table과 TLB다

CPU가 memory에 접근할 때마다 Virtual address를 Physical address로 바꿔야 한다면, 매번 Page table을 직접 따라가는 비용이 커질 수 있습니다.

그래서 hardware는 최근 address translation 결과를 TLB에 cache합니다.

TLB에 원하는 translation이 있으면 빠르게 Physical address를 얻을 수 있고, 없으면 Page table lookup을 수행해야 합니다.

 

상황	무슨 일이 일어나는가	성능 영향
TLB hit	Virtual page에서 Physical frame으로 가는 translation을 바로 찾음	빠름
TLB miss	Page table을 확인해 translation을 찾음	추가 비용 발생
Page present	Page table entry가 valid이고 Physical frame이 있음	TLB 갱신 후 접근 가능
Page fault	필요한 page가 현재 Physical memory에 없거나 접근 권한이 맞지 않음	kernel 개입, 경우에 따라 큰 latency

TLB는 작지만 매우 중요한 cache입니다.

연속적인 memory를 순차 접근하면 적은 수의 page를 반복해서 쓰기 때문에 TLB locality를 얻기 쉽습니다.

반대로 큰 memory 영역을 page 단위로 넓게 뛰어다니면 TLB miss가 늘어날 수 있습니다.

 

---

4. 그림으로 이해하기

Virtual address가 실제 memory 접근으로 이어지는 흐름을 단순화하면 다음처럼 볼 수 있습니다.

 

TLB hit이면 address translation이 빠르게 끝나고, TLB miss 뒤 Page table에서도 page를 찾지 못하면 Page fault handler가 개입합니다.

 

이 그림에서 핵심은 memory access가 항상 같은 비용이 아니라는 점입니다.

TLB hit, TLB miss, Page fault는 모두 같은 source code의 load/store 뒤에서 발생할 수 있지만 latency는 크게 달라질 수 있습니다.

그래서 성능을 볼 때는 algorithm complexity만 아니라 data layout과 access pattern도 함께 봐야 합니다.

 

---

5. Page fault는 언제 발생하나?

Page fault는 CPU가 접근하려는 Virtual page에 대해 즉시 사용할 수 있는 valid translation을 얻지 못했을 때 발생합니다.

이름만 보면 무조건 error처럼 보이지만, 항상 bug라는 뜻은 아닙니다.

운영체제는 Page fault를 이용해 lazy allocation, demand paging, memory mapped file loading, copy-on-write를 구현합니다.

 

Page fault 유형	예시	개발자가 보는 증상
Demand paging	처음 접근한 page를 그때 Physical memory에 올림	초기 접근 latency 증가
Copy-on-write	공유하던 page에 write가 발생해 private copy 생성	fork 이후 write 비용 증가 가능
Memory mapped file	file의 일부 page를 접근 시점에 읽음	random access에서 IO latency 발생 가능
Protection fault	권한 없는 address에 write 또는 execute 시도	segmentation fault 같은 crash

실무에서 Page fault를 볼 때는 major page fault와 minor page fault를 구분하면 좋습니다.

Minor page fault는 disk IO 없이 kernel이 mapping만 갱신해 해결할 수 있는 경우가 많습니다.

Major page fault는 disk에서 page를 읽어야 할 수 있어 latency가 훨씬 커질 수 있습니다.

따라서 monitoring에서 page fault count만 보는 것보다 major fault, RSS, working set, swap 사용량을 함께 봐야 합니다.

 

---

6. C++ 코드로 연결해보기

다음 예제는 page 크기를 4096 bytes로 가정하고 buffer를 page-sized step으로 접근합니다.

이 코드는 실제 Page fault 수를 측정하는 도구가 아니라, memory를 page 단위로 바라보는 감각을 위한 짧은 예제입니다.

#include <cstddef>
#include <iostream>
#include <vector>

int main()
{
    constexpr std::size_t page_size = 4096;
    constexpr std::size_t page_count = 8;
    std::vector<unsigned char> buffer(page_size * page_count);

    std::size_t touched_pages = 0;

    for (std::size_t offset = 0; offset < buffer.size(); offset += page_size) {
        buffer[offset] = static_cast<unsigned char>(offset / page_size);
        ++touched_pages;
    }

    std::cout << "buffer size: " << buffer.size() << " bytes\n";
    std::cout << "page-sized steps: " << touched_pages << '\n';
}

 

실행 결과

buffer size: 32768 bytes
page-sized steps: 8

 

실제 page size는 운영체제와 hardware 설정에 따라 다를 수 있습니다.

또한 이 예제의 출력은 Page fault 발생 횟수를 보여주지 않습니다.

다만 큰 buffer를 접근할 때 byte 단위가 아니라 page 단위의 locality도 함께 생각해야 한다는 점을 보여줍니다.

실제 분석에서는 perf, vmstat, sar, Activity Monitor, Instruments 같은 도구로 page fault와 memory pressure를 측정해야 합니다.

 

---

7. 면접 질문 예시

이 주제는 운영체제 memory 관리와 성능 감각을 함께 묻기 좋습니다.

1. Virtual memory가 필요한 이유를 설명해보세요.
   Process isolation, memory protection, 독립적인 address space, demand paging, memory mapped file 같은 기능을 가능하게 한다고 설명하면 좋습니다.
2. Page fault는 항상 program bug인가요?
   아닙니다. Demand paging이나 copy-on-write처럼 정상적인 운영체제 동작에서도 Page fault가 발생할 수 있습니다. 다만 권한 없는 접근이면 crash로 이어질 수 있습니다.
3. TLB는 왜 필요한가요?
   매 memory access마다 Page table을 직접 조회하면 비용이 크기 때문에, 최근 address translation을 cache해 Virtual address에서 Physical address로의 변환을 빠르게 하기 위해 필요합니다.

좋은 답변은 용어 정의에서 끝나지 않습니다.

Page table lookup 비용, TLB locality, major page fault latency, data access pattern까지 연결하면 실무적인 답변이 됩니다.

 

---

8. 자주 하는 오해

1. Virtual memory는 swap을 쓰기 위한 기능이다.
   Swap은 Virtual memory를 활용하는 기능 중 하나입니다. 핵심은 address translation, isolation, protection, lazy allocation입니다.
2. Pointer 값은 Physical address다.
   일반 application에서 보는 pointer 값은 대부분 Virtual address입니다. Physical address는 운영체제와 hardware가 관리합니다.
3. Page fault는 항상 fatal error다.
   정상적인 demand paging에서도 Page fault가 발생합니다. fatal한 경우는 접근 권한 위반이나 존재하지 않는 address 접근처럼 처리할 수 없는 fault입니다.
4. Memory access 비용은 모두 비슷하다.
   Cache hit, cache miss, TLB miss, Page fault는 같은 코드의 memory access 뒤에서도 완전히 다른 latency를 만들 수 있습니다.

핵심은 Page fault를 무조건 피해야 할 error로 보거나, Virtual memory를 단순히 큰 memory처럼 보는 시각을 버리는 것입니다.

 

---

9. 실무에서는 어떻게 볼까?

실무에서 Virtual memory 관련 문제는 보통 느린 요청, 갑작스러운 latency spike, RSS 증가, swap 사용, container memory limit 초과 같은 증상으로 나타납니다.

이때는 단순히 “memory가 부족하다”고 결론내리기보다 어떤 page가 실제로 자주 쓰이는지 봐야 합니다.

큰 vector나 hash table을 넓게 순회하는 코드, memory mapped file을 random access하는 코드, 많은 Process를 fork한 뒤 write가 잦은 구조에서는 Page fault와 TLB locality가 성능에 영향을 줄 수 있습니다.

증상	확인할 지표	가능한 해석
처음 요청만 느림	minor fault, lazy allocation	page가 첫 접근 시점에 준비될 수 있음
간헐적 latency spike	major fault, disk IO, swap	필요한 page를 disk에서 읽고 있을 수 있음
큰 배열 순회가 예상보다 느림	cache miss, TLB miss	access pattern이 locality를 깨뜨릴 수 있음
fork 이후 memory 사용 증가	copy-on-write page	공유 page에 write가 발생해 private copy가 늘 수 있음

C++ 개발자는 container 선택과 data layout을 볼 때 cache locality만 아니라 TLB locality도 함께 생각하면 좋습니다.

예를 들어 작은 객체가 여기저기 흩어져 있으면 pointer chasing이 늘고, CPU cache와 TLB 모두에 불리할 수 있습니다.

반대로 연속된 memory를 순차적으로 접근하면 hardware prefetch, cache line, TLB 측면에서 유리한 경우가 많습니다.

 

---

10. 정리

Virtual memory는 Process가 독립된 address space를 가진 것처럼 보이게 하는 address translation 모델입니다.

Page table은 Virtual page와 Physical frame의 매핑 정보를 관리합니다.

TLB는 최근 address translation을 cache해 memory access 비용을 줄입니다.

Page fault는 항상 bug가 아니며, demand paging이나 copy-on-write에서도 정상적으로 발생할 수 있습니다.

실무에서는 RSS, working set, major fault, access pattern, TLB locality를 함께 봐야 합니다.

 

Virtual memory를 이해하면 pointer, allocation, Process isolation, memory pressure, latency spike를 운영체제 관점에서 함께 해석할 수 있습니다.

 

---