도구스개발

페이징 주소 변환 계산기

페이지 크기와 주소 비트 수에서 페이지 번호·오프셋 비트를 쪼개고 페이지 테이블 크기와 다단계 분할, TLB 실효 접근 시간(EAT)을 계산합니다. 가상주소 하나를 물리주소로 직접 바꿔 볼 수 있습니다.

비트
비트

가상보다 클 수도 작을 수도 있습니다. 프레임 수를 정합니다.

1이면 평면 테이블입니다.

가상주소 쪼개기

10 | 10 | 12

페이지 1,048,576개 · 프레임 1,048,576개

오프셋 비트 = log₂(페이지 크기)12비트
페이지 번호 비트20비트
프레임 번호 비트20비트
가상 페이지 수1,048,576개
평면 테이블 하나의 크기4MB
한 페이지에 들어가는 항목 수1,024개 (10비트)
최상위 테이블 크기4KB
프로세스당 평균 내부 단편화2KB
평면 페이지 테이블이 4MB입니다 — 프로세스마다. 페이지가 1,048,576개이고 항목 하나가 4바이트이기 때문입니다. 프로세스 100개면 이것만 400MB입니다. 다단계 페이지 테이블이 나온 이유가 이 크기이고, 다단계가 아끼는 것은 안 쓰는 구간의 하위 테이블을 아예 만들지 않는 것입니다 — 최상위 테이블 4KB만 늘 두고, 실제로 쓰는 구간의 하위 테이블만 붙입니다.
단계당 비트는 항목 크기가 정합니다. 테이블 하나가 페이지 하나에 딱 들어가야 하므로, 페이지 4KB에 항목 4바이트면 한 테이블에 1,024개, 곧 10비트씩입니다. 그래서 이 구성의 «자연스러운» 단계 수는 2단계입니다. 4KB 페이지에 4바이트 항목이면 10비트씩이라 32비트가 10|10|12로 나뉘고(x86 32비트), 4KB에 8바이트 항목이면 9비트씩이라 48비트가 9|9|9|9|12로 나뉩니다(x86-64).

페이지 테이블이 알려 주는 값입니다. 여기서는 직접 넣어 봅니다.

페이지 번호 (주소 ÷ 페이지 크기)2번
오프셋 (나머지)808바이트
물리주소 = 프레임 × 페이지 크기 + 오프셋29,480
오프셋은 변환하지 않고 그대로 통과합니다. 페이지 안에서의 위치는 어느 프레임으로 옮겨지든 그대로이기 때문입니다. 바뀌는 것은 앞쪽 번호뿐이라 2번 페이지가 7번 프레임에 있다면 물리주소는 7 × 4,096 + 808 = 29,480입니다. 페이지 크기를 2의 거듭제곱으로 두는 이유가 여기 있습니다 — 나눗셈 없이 비트를 자르는 것만으로 쪼개집니다.
%
ns
ns

0으로 두면 TLB 탐색이 공짜라고 보는 교재 관행에 맞습니다.

TLB 히트일 때100ns
TLB 미스일 때300ns
실효 접근 시간(EAT)104ns
변환이 없을 때의 몇 배1.04배
EAT = h(t_TLB + t_메모리) + (1−h)(t_TLB + (단계+1)×t_메모리) TLB가 빗나가면 페이지 테이블을 2번 읽고 나서야 데이터를 읽기 때문입니다. 지금 적중률 98%에서 104ns이고, 적중률이 2%p만 떨어져도 108ns가 됩니다. 교재마다 규약이 다릅니다 — TLB 탐색 시간을 빼거나 미스일 때 TLB를 두 번 세기도 하므로, 답을 견줄 때는 어느 식인지부터 맞춰야 합니다.
페이지를 키우면 테이블은 작아지고 낭비는 커집니다. 페이지가 커질수록 페이지 수가 줄어 테이블이 작아지지만, 마지막 페이지에서 버려지는 내부 단편화가 평균 페이지 크기의 절반까지 늘어납니다. 지금은 프로세스당 평균 2KB입니다. 4KB가 오래 표준으로 남은 것이 이 줄다리기의 결과이고, 큰 페이지(2MB·1GB)는 TLB 적중률이 중요한 데이터베이스 같은 곳에서 골라 씁니다.

사용 방법

  1. 1페이지 크기와 가상·물리주소 비트 수를 넣습니다.
  2. 2페이지 번호와 오프셋 비트 폭, 평면 페이지 테이블 크기를 확인합니다.
  3. 3단계 수를 고르면 단계별 비트 폭과 최상위 테이블 크기가 나옵니다.
  4. 4가상주소와 프레임 번호를 넣어 물리주소를 직접 만들어 보고, TLB 적중률로 실효 접근 시간을 봅니다.

자주 묻는 질문

오프셋 비트 = log₂(페이지 크기)이고, 나머지 앞쪽이 모두 페이지 번호입니다. 32비트 주소에 4KB 페이지면 오프셋 12비트, 페이지 번호 20비트입니다. 페이지 크기를 2의 거듭제곱으로 두는 이유가 이것으로, 나눗셈 없이 비트를 자르는 것만으로 쪼개집니다.

페이지 수 × 항목 크기입니다. 32비트 주소에 4KB 페이지면 페이지가 2²⁰ = 1,048,576개이고, 항목이 4바이트면 테이블 하나가 4MB입니다. 이것이 프로세스마다 필요해서 프로세스 100개면 400MB가 테이블에만 듭니다 — 다단계 페이지 테이블이 나온 이유입니다.

테이블 하나가 페이지 하나에 딱 들어가도록 log₂(페이지 크기 ÷ 항목 크기)비트씩 씁니다. 4KB 페이지에 4바이트 항목이면 1,024개, 곧 10비트씩이라 32비트 주소가 10|10|12로 나뉩니다(x86 32비트). 4KB에 8바이트 항목이면 512개, 9비트씩이라 48비트 주소가 9|9|9|9|12로 나뉩니다(x86-64).

EAT = h(t_TLB + t_메모리) + (1−h)(t_TLB + (단계+1)×t_메모리)입니다. TLB가 빗나가면 페이지 테이블을 단계 수만큼 읽고 나서 데이터를 읽기 때문입니다. 적중률 98%, 메모리 100ns, 단일 단계에 TLB 탐색이 공짜라면 102ns가 됩니다. 교재마다 TLB 탐색 시간을 세는 방식이 달라 답이 갈리니 규약을 먼저 맞춰야 합니다.

페이지 수가 줄어 페이지 테이블이 작아지고 TLB 적중률이 올라갑니다. 대신 마지막 페이지에서 버려지는 내부 단편화가 평균 페이지 크기의 절반까지 커집니다. 4KB가 오래 표준으로 남은 것이 이 줄다리기의 결과이며, 큰 페이지(2MB·1GB)는 데이터베이스처럼 TLB가 중요한 곳에서 골라 씁니다.

전송되지 않습니다. 모든 계산은 브라우저 안에서 이뤄지고, 입력값은 이 기기에만 남습니다.

알아두면 좋은 점

  • EAT 식은 TLB 미스일 때 페이지 테이블을 단계 수만큼 읽고 데이터를 한 번 더 읽는다고 봅니다. TLB 탐색 시간을 빼거나 미스일 때 TLB를 두 번 세는 교재도 있어, 다른 답과 견줄 때는 규약부터 맞춰야 합니다.
  • 단계별 비트 분할은 «하위 테이블 하나가 페이지 하나에 들어간다»는 관행을 따릅니다. 단계 수를 그보다 적게 잡으면 최상위 테이블이 페이지보다 커지며, 실제 구조에서도 최상위만 크게 두는 설계가 있습니다.
  • 역페이지 테이블·해시 페이지 테이블은 여기서 다루지 않습니다. 그쪽은 물리 프레임 수만큼만 항목을 두어 크기가 가상주소 공간과 무관해집니다.
  • 내부 단편화 «페이지 크기의 절반»은 마지막 페이지가 고르게 찬다고 볼 때의 평균입니다. 실제로는 프로세스가 여러 영역(코드·데이터·스택)을 따로 잡아 이보다 큽니다.
  • 접근 시간은 캐시를 고려하지 않은 값입니다. 실제로는 페이지 테이블 읽기도 캐시에 걸려 훨씬 빠릅니다.

함께 보면 좋은 도구

마지막 검증: 2026년 9월 1일 · 결과는 참고용 추정치입니다.