나는 수년 동안 이것을 알아내려고 노력해 왔지만 매번 이해하지 못했습니다. 나는 페이징, 페이지 테이블, 페이지 테이블 디렉토리가 Linux에서 어떻게 작동하는지 잘 알고 있지만 실제로 왜 필요한지는 이해하지 못합니다.
페이징 및 페이지 테이블 수준(Linux에서는 4개 수준을 사용함)이 필요한 이유는 모든 메모리를 동시에 로드할 수 없다는 점인 것 같습니다. 하지만 모든 디렉토리를 로드하지 않고 선택한 수의 페이지와 주소만 로드할 수는 없을까요?
특정 프레임이 물리적 메모리의 어디에 있는지 알아야 하지만 왜 거대한 페이지 테이블의 하위 집합을 검색할 수 없는 걸까요? 그것이 어떤 문제를 일으키는가? 페이지 + 오프셋을 사용하지 않으면 모든 것이 너무 커질 것이라는 것을 알고 있지만 디렉토리가 실제로 문제를 해결합니까?
다양한 시스템이 페이지 테이블 레벨을 구축하기 위해 주소의 비트를 나누는 방법에 대해 많은 논의가 있지만 결국 우리는 항상 항목에 대해 32/64비트로 끝납니다. 우리는 더 많은 문제를 해결할 수 없습니다( cr3PAE와 같은 레지스터에 대한 트릭 제외). 그렇다면 문제를 분할하는 이유는 무엇입니까? 마지막으로 (간단하게 설명하겠습니다) 단순히 "주소 3572"라고 말하는 것보다 "디렉터리 3, 하위 디렉터리 5, 페이지 7, 오프셋 2"가 더 낫습니까?
더 나쁜 것은, CPU가 우리에게 도움이 되지 않는다면(내 생각엔 1클록 주기에 모든 것을 할 수 있는 회로가 내장되어 있는 것 같은데? 확실하지 않습니다!), 모든 것을 검색해야 한다면 효율성이 훨씬 낮아지지 않을까요? 논리적/물리적 메모리 맵을 직접 검색한 다음 필요한 주소에 액세스하는 대신 모든 메모리 액세스 시 디렉터리 및 하위 디렉터리를 관리합니까?
답변1
여러 레벨을 갖는 이유는 공간을 절약하기 위해서입니다.
여러 수준을 사용할 수 없는 경우 무엇이 필요한지 고려하십시오. 48비트 주소 공간이 있고(현재 x86_64 CPU는 전체 64비트를 제공하지 않음) 4k 바이트 페이지 크기(12비트)를 사용하는 경우 2의 36제곱 페이지를 갖게 됩니다.
매핑 정보를 64비트(8바이트)에 맞출 수 있는 경우 변환 테이블을 보관하려면 8 * 2**36바이트 또는 512GB의 메모리가 필요합니다.
테이블의 거의 모든 항목은 "잘못된 주소"를 나타내는 값으로 설정됩니다.
여러 수준을 통해 변환 테이블의 공간 요구 사항을 줄일 수 있습니다. 64비트 주소 공간이 current_unused/PML4/PDPT/PD/PT/address_in_page의 16/9/9/9/9/12비트로 나누어지면 PML4 테이블에는 512개의 항목만 필요하며 그 중 510개는 값일 수 있습니다. "잘못된 주소"를 나타내고 나머지 2는 PDPT의 512 항목 배열 두 개를 가리킵니다. 여기서 멈추면 필요한 공간을 2**36개 항목에서 약 2 + 2**27개 항목으로 줄였으며 이는 원래 선형 요구 사항의 0.2% 미만입니다. 물론 거기서 끝나지 않고 3개의 추가 레벨이 있지만 그다지 큰 비용 절감 효과를 제공하지는 않습니다.