가상 메모리 접근은 가상 주소를 물리 주소로 바꾸는 단계, 페이지가 현재 준비돼 있는지 확인하는 단계, 실제 데이터 캐시에서 바이트를 가져오는 단계를 포함합니다. TLB miss·페이지 폴트·I/O는 서로 겹칠 수 있지만 같은 사건은 아니므로, 첫 접근의 정상적인 준비 비용과 메모리 압박으로 인한 반복 비용을 별도로 관찰해야 합니다.
주소 접근과 페이지 준비 비용
프로그램이 큰 배열을 할당하고 첫 번째 요청에서 처음 접근하자 지연이 늘었다고 합시다. 호스트에는 여유 메모리가 있고 swap도 쓰지 않았습니다. 그런데 페이지 폴트 수가 증가합니다. 상태 trace를 가상 주소 생성 → TLB hit/miss → 페이지 테이블 유효성 → minor/major fault 여부 → 데이터 캐시 접근으로 분해합니다. 첫 pass에서 minor fault와 RSS가 늘고 second pass에서 줄면 지연 할당 준비의 설명과 맞지만, major fault·reclaim·I/O 대기가 반복되면 같은 숫자를 메모리 압박 신호로 해석해야 합니다.
이것만으로 메모리 부족이라고 판단하면 정상적인 첫 접근 준비를 누수나 디스크 문제로 오해하게 됩니다.
프로그램의 가상 주소는 물리 메모리 주소와 같지 않습니다. 페이지 단위의 변환과 접근 권한을 확인해야 하며, 아직 준비되지 않은 매핑에는 운영체제 개입이 필요할 수 있습니다. 주소 변환을 찾지 못한 것, 페이지 접근을 바로 완료하지 못한 것, 데이터 캐시에 내용이 없는 것은 서로 다른 사건입니다.
가상 주소의 페이지 번호·내부 위치 분해
페이지 크기가 4,096바이트인 단순한 모형에서 가상 주소 10,000은 페이지 번호 2, 페이지 내부 offset 1,808입니다. 페이지 테이블이 가상 페이지 2를 물리 프레임 50에 연결했다면 물리 주소는 50×4096+1808=206608입니다.
페이지 테이블에는 프레임 번호뿐 아니라 유효 여부와 읽기·쓰기 등의 권한 정보도 있습니다. CPU가 매번 여러 단계의 테이블을 읽지 않도록 최근 변환을 TLB(translation lookaside buffer)에 보관합니다. 실제 테이블 구조와 하드웨어·소프트웨어의 분담은 아키텍처에 따라 다르며, 아래는 흔한 하드웨어 페이지 테이블 탐색을 가정합니다.
그림을 글로 읽기
- 가상 주소 접근: 페이지 번호 + 내부 offset
- TLB 조회: 변환과 권한 캐시
- 페이지 테이블 탐색: TLB miss 때 수행
- 유효한 매핑: 변환 저장 후 메모리 접근
- 페이지 폴트 처리: 매핑 준비 또는 접근 오류
- 가상 주소 접근 → TLB 조회: 변환 요청
- TLB 조회 → 페이지 테이블 탐색: 변환 캐시 miss
- 페이지 테이블 탐색 → 유효한 매핑: 유효·권한 충족
- 페이지 테이블 탐색 → 페이지 폴트 처리: 즉시 접근 불가
TLB에서 변환을 찾지 못하면 CPU는 페이지 테이블을 다시 확인하고, 유효한 매핑과 권한을 찾으면 그 변환을 사용해 메모리 접근을 계속할 수 있습니다. 이 경우 TLB miss는 있었지만 페이지 폴트가 반드시 발생한 것은 아닙니다. 반대로 TLB hit라도 저장된 권한이 현재 접근을 허용하지 않으면 접근 예외가 날 수 있으므로, “TLB hit이면 어떤 접근도 성공한다”고 해석하면 안 됩니다.
페이지 폴트 처리 유형의 구분
| 상황 | 필요한 처리의 예 | 저장장치 읽기가 필수인가 |
|---|---|---|
| 익명 메모리 첫 쓰기 | 물리 페이지 준비·초기화·매핑 | 보통 아님 |
| 이미 page cache에 있는 파일 매핑 | 현재 프로세스의 매핑 추가 | 아님 |
| copy-on-write 페이지 쓰기 | 사본 생성·매핑 변경 | 원본이 메모리에 있으면 아님 |
| 메모리에 없는 파일 페이지 접근 | 파일 내용을 읽어 준비 | 필요할 수 있음 |
| 잘못된 주소·권한 위반 | 오류 신호 또는 프로세스 종료 | 메모리 증설로 해결 안 됨 |
Linux 등에서 저장장치 읽기 없이 처리되는 경우를 minor fault, 읽기가 필요한 경우를 major fault로 구분해 관찰할 수 있습니다. OS의 정확한 집계 정의는 확인해야 하며, 페이지 폴트 개수와 디스크 읽기 요청 수가 1:1이라고 보지 않습니다. 미리 읽기와 캐시·공유 페이지가 영향을 줍니다.
첫 접근과 재접근 비용 비교
큰 익명 버퍼를 예약만 했을 때는 가상 주소 공간은 커져도 모든 페이지가 상주하지 않을 수 있습니다. 페이지마다 한 바이트씩 처음 쓰면 페이지가 준비되어 minor fault와 RSS가 증가할 수 있습니다. 같은 범위를 다시 쓰면 이미 준비된 페이지를 재사용하므로 첫 접근과 다른 비용이 나옵니다.
reserve N pages
record baseline counters
for each page:
write one byte # 첫 접근 준비 비용
record first-pass counters
for each page:
write one byte # 이미 준비된 상태와 비교
record second-pass counters
이 실험에서도 컴파일러가 접근을 없애지 않게 하고, 실제로 수행한 쓰기량과 접근 패턴을 확인해야 합니다. 예열은 첫 요청 지연을 줄일 수 있지만 사용하지 않을 페이지까지 메모리를 차지하고 시작 시간을 늘립니다. “폴트가 줄었으니 무조건 개선”이라고 하지 않습니다.
작업 집합 축출과 반복 접근 비용
첫 접근 뒤 안정되는 것과, 자주 쓰는 페이지가 계속 쫓겨나 다시 읽히는 것은 다릅니다. 여러 프로세스·컨테이너의 작업 집합이 유효 메모리 예산을 넘으면 회수와 재접근이 반복될 수 있습니다. 이때 reclaim·major fault·page-in·I/O 대기와 요청 지연을 함께 봅니다.
호스트 전체 여유 메모리가 있어도 컨테이너 한도나 NUMA 배치, 파일 캐시 경쟁 때문에 해당 작업은 압박받을 수 있습니다. 데이터 접근 지역성을 높이거나 동시 작업 수를 줄여 작업 집합을 작게 만드는 방법도 메모리 증설과 비교해야 합니다.
큰 페이지와 TLB 변환 범위
가령 TLB 항목 64개가 모두 4KiB 페이지를 가리킨다면 단순 계산상 256KiB의 주소 범위를 덮습니다. 같은 항목 수로 2MiB 페이지를 가리키면 128MiB입니다. 이 TLB reach 계산은 원리를 보여 주는 예이며, 실제 CPU의 페이지 크기별 TLB 계층과 연관도는 다를 수 있습니다.
큰 페이지는 변환 miss를 줄이는 대신 큰 단위의 할당·초기화·회수와 내부 낭비를 만들 수 있습니다. 프로세스 전환 때 ASID·PCID 같은 주소 공간 태그가 변환 재사용을 돕기도 하지만 모든 전환에서 TLB를 전부 비우거나 전부 유지한다고 일반화하지 않습니다. 매핑 변경 뒤 다른 코어의 낡은 변환을 무효화하는 비용도 따로 있습니다.
TLB·페이지 폴트·I/O 원인의 분리
TLB miss가 증가했지만 폴트와 디스크 대기가 없다면 변환 탐색 비용을 먼저 살핍니다. 시작 구간에만 minor fault가 몰리면 지연 할당·매핑 준비를 의심합니다. 장시간 major fault·회수·저장장치 지연이 반복되면 작업 집합 유지 문제를 살핍니다.
동일 데이터로 연속 순회와 페이지별 무작위 접근, 예열 전후를 비교하고 TLB miss·페이지 테이블 탐색·데이터 캐시 miss·minor/major fault·RSS·요청 지연을 함께 기록합니다. 실습의 예상 결과는 4KiB 페이지 수만큼 첫 쓰기의 fault/RSS 변화가 나타나고 같은 페이지의 두 번째 쓰기에서는 해당 준비 fault가 크게 줄어드는 것입니다. 다만 컴파일러 최적화, 사전 touch, 공유 페이지, 컨테이너 한도와 플랫폼 카운터 정의가 결과를 바꿀 수 있으므로, 첫 pass와 second pass의 접근량·환경·카운터를 함께 저장해야 합니다.