CPU는 램 데이터를 어떻게 찾나? 가상 주소와 DRAM 매핑

메모리 접근이 느린데 주소 변환과 램 지연 중 어디가 원인인지 모르겠다면, CPU가 램 데이터를 찾는 전체 경로를 층별로 나눠 확인해야 합니다.
가장 빠른 해법은 가상 주소가 티엘비나 페이지 테이블을 통해 물리 주소로 바뀐 뒤, 캐시와 메모리 제어기를 거쳐 디램 위치로 해석된다는 순서를 기준으로 측정하는 것입니다.

이 글은 가상 주소와 물리 주소를 같은 개념으로 이해해 혼란스러운 운영체제 학습자를 위한 내용입니다. 캐시 적중 실패와 메모리 지연을 구분해야 하는 성능 엔지니어, 페이지 테이블·로우해머·가상화 주소 변환을 다루는 보안 개발자도 참고할 수 있습니다.

프로그램이 만드는 주소는 실제 램 위치가 아닙니다

프로그램의 로드 명령이 포인터를 읽을 때 처음 만들어지는 값은 보통 가상 주소입니다. 이 주소는 현재 프로세스의 주소 공간 안에서만 의미가 있습니다. 운영체제는 프로세스마다 페이지 테이블을 다르게 구성하므로, 서로 다른 프로세스가 같은 가상 주소를 사용해도 서로 다른 물리 메모리 페이지를 가리킬 수 있습니다.

리눅스 커널 문서에서도 페이지 테이블을 프로세서가 사용하는 가상 주소와 실제 메모리 시스템이 사용하는 물리 주소를 연결하는 구조로 설명합니다. 자세한 기본 구조는 리눅스 페이지 테이블 문서에서 확인할 수 있습니다.

역할을 나누면 다음과 같습니다.

• 프로그램은 포인터와 명령을 통해 가상 주소를 만듭니다.
• 메모리 관리 장치는 가상 주소를 물리 주소로 변환합니다.
• 운영체제는 페이지 테이블, 접근 권한, 페이지 적재 상태를 관리합니다.
• 메모리 제어기는 물리 주소를 메모리 채널과 디램 내부 요청으로 해석합니다.

가상 주소에는 보통 가상 페이지 번호와 페이지 내부 위치를 나타내는 오프셋이 함께 들어 있습니다. 주소 변환 과정에서 바뀌는 것은 페이지 번호입니다. 같은 페이지 안에서 읽는 위치를 나타내는 오프셋은 그대로 유지됩니다.

따라서 가상 주소를 특정 램 칩의 위치라고 보면 안 됩니다. 가상 주소는 프로그램이 사용하는 논리적인 위치이고, 물리 주소는 운영체제와 하드웨어가 연결한 실제 메모리 주소 공간의 위치입니다.

가상 주소는 어떻게 물리 주소로 바뀌나요?

메모리 관리 장치는 먼저 티엘비를 확인합니다. 티엘비는 최근에 사용한 가상 페이지와 물리 페이지의 변환 결과를 저장하는 작은 하드웨어 캐시입니다. 같은 페이지에 반복해서 접근하면 페이지 테이블을 매번 처음부터 읽지 않고 티엘비의 결과를 사용할 수 있습니다.

티엘비 적중 경로는 다음과 같습니다.

1. 로드 명령이 가상 주소를 생성합니다.
2. 메모리 관리 장치가 가상 페이지 번호로 티엘비를 조회합니다.
3. 티엘비에서 물리 페이지 번호를 찾습니다.
4. 물리 페이지 번호와 기존 오프셋을 합쳐 물리 주소를 만듭니다.
5. 만들어진 물리 주소로 캐시 계층을 확인합니다.

예를 들어 가상 주소가 어떤 페이지의 시작점에서 128바이트 떨어진 위치를 가리킨다면, 주소 변환 뒤에도 페이지 안쪽 위치는 128바이트로 유지됩니다. 바뀌는 부분은 해당 페이지가 실제 물리 메모리의 어느 프레임에 연결되는지입니다.

티엘비가 빗나가면 무슨 일이 생기나요?

티엘비 미스가 발생하면 메모리 관리 장치는 페이지 테이블 워크를 수행합니다. 페이지 테이블은 메모리에 저장되지만, 최상위 페이지 테이블의 위치는 프로세서가 관리하는 제어 레지스터를 통해 찾습니다. 이후 가상 주소의 상위 비트를 사용해 여러 단계의 페이지 테이블 항목을 차례로 조회합니다.

리눅스의 일반적인 페이지 테이블 코드는 최대 5단계 구조를 기준으로 설명되며, 실제 하드웨어가 사용하지 않는 단계는 접어서 처리할 수 있습니다. 단계 수는 프로세서 구조와 운영체제 설정에 따라 달라질 수 있으므로, 모든 시스템이 같은 횟수의 메모리 조회를 수행한다고 가정해서는 안 됩니다.

페이지 테이블 항목에는 다음과 같은 정보가 들어갈 수 있습니다.

• 해당 페이지가 현재 물리 메모리에 있는지 여부
• 읽기·쓰기·실행 권한
• 사용자 영역과 커널 영역의 구분
• 접근되었거나 수정되었는지 나타내는 상태
• 큰 페이지 사용 여부

페이지 테이블 항목이 유효하지 않거나 접근 권한이 맞지 않으면 페이지 폴트가 발생합니다. 페이지 폴트가 항상 프로그램 오류를 뜻하는 것은 아닙니다. 아직 물리 메모리에 배치하지 않은 페이지를 처음 요청했거나, 복사 시점 지연 방식으로 공유된 페이지를 수정하려는 경우에도 발생할 수 있습니다.

반대로 허용되지 않은 영역에 접근하면 운영체제가 프로세스를 종료할 수 있습니다. 페이지 테이블과 메모리 관리의 기본 동작은 리눅스 메모리 관리 문서에서 확인할 수 있습니다.

물리 주소가 곧 램 칩 위치인가요?

아닙니다. 물리 주소는 프로세서와 메모리 시스템이 사용하는 주소 공간의 값입니다. 이 값이 특정 디램 칩, 랭크, 뱅크, 행, 열로 어떻게 나뉘는지는 메모리 제어기와 플랫폼 설계에 따라 달라집니다.

주소 변환 뒤의 물리 주소는 대략 다음 선택에 사용될 수 있습니다.

• 메모리 채널
• 랭크
• 뱅크 또는 뱅크 그룹
• 디램 행
• 디램 열

하지만 물리 주소의 특정 비트가 언제나 행 주소가 되는 것은 아닙니다. 일부 플랫폼은 성능을 높이기 위해 주소 비트를 섞거나, 여러 채널과 뱅크에 접근을 분산하는 함수를 사용할 수 있습니다.

그러므로 다음과 같은 고정 설명은 피해야 합니다.

상위 비트는 행, 중간 비트는 뱅크, 하위 비트는 열이다.

이 방식은 특정 실험 환경의 예일 수 있지만, 모든 프로세서와 메모리 모듈에 적용되는 공식 규칙은 아닙니다. 디램 주소 매핑을 분석한 연구에서도 채널·랭크·뱅크 선택 규칙을 플랫폼별로 확인해야 한다고 설명합니다. 디램 주소 매핑 역공학 연구를 참고하면 로우해머와 메모리 채널 분석에서 플랫폼 정보가 중요한 이유를 이해할 수 있습니다.

디램 뱅크와 행 주소는 어떻게 결정되나요?

메모리 제어기는 물리 주소를 메모리 요청으로 변환합니다. 주소 일부는 채널과 랭크를 선택하고, 나머지는 뱅크·행·열을 선택하는 데 사용될 수 있습니다. 디램은 먼저 행을 열어 행 버퍼에 준비한 뒤, 열 위치의 데이터를 읽는 방식으로 동작한다고 이해하면 됩니다.

실제 비트 배치는 다음 조건에 따라 달라질 수 있습니다.

• 프로세서 세대
• 메모리 제어기 설계
• 메모리 규격과 모듈 구성
• 채널 수와 랭크 구성
• 성능을 위한 주소 인터리빙 정책
• 펌웨어와 플랫폼 설정

따라서 보안 분석이나 성능 튜닝에서 뱅크 충돌을 확인하려면 해당 장비에서 직접 측정하거나, 해당 플랫폼에 맞는 연구 자료를 사용해야 합니다. 일반적인 물리 주소만 보고 디램 행을 확정해서는 안 됩니다.

캐시가 있으면 디램까지 가지 않을 수 있습니다

물리 주소가 만들어졌다고 해서 요청이 바로 램으로 전송되는 것은 아닙니다. 프로세서는 먼저 캐시 계층에서 해당 데이터가 이미 준비되어 있는지 확인합니다. 캐시 적중이면 디램 접근 없이 데이터를 반환할 수 있습니다. 캐시 미스일 때만 더 낮은 캐시나 메모리 제어기로 요청이 내려갑니다.

성능 측정에서는 다음 세 구간을 분리해야 합니다.

티엘비도 캐시의 한 종류이지만, 저장하는 대상은 일반 데이터가 아니라 주소 변환 결과입니다. 페이지 테이블이 바뀐 뒤 오래된 티엘비 항목이 남아 있으면 잘못된 주소 변환이 사용될 수 있으므로, 프로세서는 필요한 범위의 티엘비를 비워야 합니다. 이 동작은 리눅스 캐시와 티엘비 갱신 문서에서 확인할 수 있습니다.

페이지 크기도 주소 변환 부담에 영향을 줍니다. 프로세서와 운영체제는 일반 페이지 외에 큰 페이지를 지원할 수 있습니다. 큰 페이지를 사용하면 같은 메모리 범위를 더 적은 페이지 항목으로 표현할 수 있어 티엘비 압박을 줄이는 데 도움이 될 수 있습니다. 그러나 내부 단편화가 커지고 메모리 관리 단위가 커질 수 있으므로, 모든 작업에 큰 페이지가 유리한 것은 아닙니다.

프로세서 세대별 페이지 크기와 페이징 기능은 다를 수 있습니다. 특정 기능을 전제로 성능을 판단하기 전에는 프로세서 시스템 프로그래밍 공식 안내서에서 해당 구조의 지원 범위를 확인해야 합니다.

하나의 로드 명령으로 전체 경로를 따라가 보기

이제 포인터가 가리키는 데이터를 읽는 상황을 하나의 로드 명령으로 연결해 보겠습니다.

1. 프로그램의 로드 명령이 가상 주소를 생성합니다.
2. 메모리 관리 장치가 티엘비를 조회합니다.
3. 티엘비가 적중하면 물리 페이지 번호를 바로 얻습니다.
4. 티엘비가 빗나가면 최상위 페이지 테이블부터 단계별 항목을 읽습니다.
5. 페이지가 없거나 권한이 틀리면 페이지 폴트 처리로 넘어갑니다.
6. 유효한 물리 주소가 만들어지면 캐시 계층을 확인합니다.
7. 캐시가 적중하면 요청한 데이터가 프로세서로 반환됩니다.
8. 캐시가 빗나가면 메모리 제어기가 물리 주소를 채널·랭크·뱅크·행·열 요청으로 해석합니다.
9. 디램에서 데이터가 준비되면 메모리 제어기를 통해 캐시로 전달됩니다.
10. 프로세서는 로드 명령의 결과를 레지스터나 후속 연산에 사용합니다.

가상화 환경에서는 이 경로가 한 번 더 복잡해질 수 있습니다. 게스트 운영체제가 만든 가상 주소를 게스트 물리 주소로 바꾼 뒤, 하이퍼바이저가 관리하는 두 번째 주소 변환을 거쳐 호스트 물리 주소에 도달하는 방식입니다.

이때 지연을 분석하려면 게스트 안에서 측정한 값인지, 호스트 시스템에서 측정한 값인지 구분해야 합니다. 원격 개발 환경이나 가상 머신에서는 추가 주소 변환, 메모리 압박, 스왑, 가상 장치 지연이 함께 나타날 수 있기 때문입니다.

원격 환경에서 결과를 비교할 때는 접속 지연과 컴퓨팅 지연을 섞지 않아야 합니다. 작업 전후에 메모리 사용량, 스왑 발생 여부, 페이지 폴트와 캐시 미스를 따로 기록하고, 같은 작업을 여러 번 반복해 변동 폭을 확인하는 방식이 안전합니다. 원격 개발 환경을 운영하는 조직의 역할과 관리 범위를 비교할 때는 회사의 지원 범위와 별개로 운영체제 버전, 가상화 여부, 메모리 제한, 저장 장치 상태를 함께 기록해야 합니다.

장시간 실행되는 에이전트의 메모리 사용량을 확인할 때도 주소 변환만 보면 안 됩니다. 프로세스별 메모리 증가, 페이지 폴트, 스왑 발생 여부, 캐시 미스를 함께 봐야 합니다. 작업별 메모리 사용량을 분리해서 관찰하려면 프로세스별 메모리와 스왑 사용량을 시간대별로 기록하는 방법이 적합합니다.

성능과 보안 문제를 나눠 점검하는 절차

다음 순서로 확인하면 원인을 비교적 빠르게 좁힐 수 있습니다.

1. 포인터 접근이 페이지 경계를 자주 넘는지 확인합니다.
2. 티엘비 미스와 페이지 폴트를 별도 지표로 수집합니다.
3. 캐시 미스가 실제 디램 접근으로 이어지는지 확인합니다.
4. 메모리 대역폭이 포화되었는지 확인합니다.
5. 특정 주소 패턴에서 뱅크 충돌이나 행 버퍼 충돌이 반복되는지 살핍니다.
6. 컨테이너나 가상 머신이라면 추가 주소 변환 계층을 분리합니다.
7. 마지막으로 실제 플랫폼의 메모리 제어기 자료와 비교합니다.

보안 연구에서는 물리 주소를 알더라도 디램 행과 뱅크를 바로 알 수 없다는 점이 중요합니다. 로우해머 실험처럼 인접 행의 관계가 필요한 경우에는 주소 매핑을 별도로 검증해야 합니다.

반대로 일반적인 성능 최적화에서는 고정된 행 번호를 알아내는 것보다 순차 접근, 데이터 지역성, 캐시 미스 감소, 메모리 병렬성 확보를 먼저 적용하는 편이 재현성이 높습니다. 특정 플랫폼의 비트 분할을 모르는 상태에서 임의의 주소 공식을 적용하면 실험 결과를 잘못 해석할 수 있습니다.

현재 사용하는 원격 개발 환경이 캐시 미스와 메모리 압박을 분석하기에 충분한지 먼저 확인해야 합니다. 직접 장비를 구매하면 하드웨어 조건을 고정할 수 있지만, 초기 비용과 관리 부담이 생깁니다. 반대로 임시 테스트나 기간이 정해진 개발 작업에서는 원격 환경이 편리하지만, 가상화 계층과 접속 지연이 측정 결과에 섞일 수 있습니다.

따라서 물리 인터페이스가 필요하거나 장기간 일정한 고부하를 유지해야 한다면 직접 구매가 더 적합합니다. 필요한 기간만 개발 환경을 구성하고 주소 변환과 메모리 사용 현상을 비교하려는 목적이라면 Kvmzen의 맥 미니 원격 대여 환경을 검토할 수 있습니다. CPU가 램 데이터를 어떻게 찾는지 이해하면, 환경을 선택할 때도 단순한 메모리 용량보다 주소 변환 계층, 캐시 상태, 가상화 여부와 측정 가능성을 함께 판단할 수 있습니다.