4

가상 메모리와 관련된 몇 가지 문제에 대답하고 있으며이 작업이 어떻게 수행되는지에 대한 이해를 돕기 위해 도움이 필요합니다. 다음 가상 메모리 계산하기 페이지 테이블 및 변환 참조 버퍼

질문

은 :

32 비트 워드와 바이트 - 어 드레서 블 시스템 4기가바이트의 가상 어드레스 공간 1기가바이트의 물리 어드레스 공간에, 4 킬로바이트 페이지 크기가 주어 . 페이지 테이블 엔트리가 4 바이트로 반올림된다는 가정이 있습니다.

a) 페이지 테이블의 크기는 몇 바이트입니까?

b) 이제 총 256 개의 주소 변환과 함께 4 방향 세트 연관 변환 lookaside 버퍼가 구현된다고 가정하십시오. 해당 태그 및 색인 필드의 크기를 계산하십시오. 다음

내 응답은 :

A :

페이지 테이블의 크기는 엔트리의 크기를 곱한 페이지 테이블에서의 엔트리의 수와 동일하다.

페이지 테이블의 항목 수는 메모리 크기를 페이지 크기로 나눈 것과 같습니다. 2^32/2^12 = 2^20.

항목의 크기는 단어 크기에서 페이지 테이블의 항목 수에 사용 된 비트 수 (32-20 = 12)를 뺀 것과 같습니다.

따라서, 페이지 테이블 크기가 (2^20) * 12 비트 = 12,582,912 비트 = 1572864 바이트

하지만, I는 this 발견 ("페이지 테이블 크기"의 제목하에), 이는 기본적으로 동일한 번호를 사용합니다.

페이지 테이블 크기 = ((가상 주소 공간의 크기)/(페이지 크기)) * (페이지 테이블 엔트리 크기) = (4 GB/4 KB) * 4 B = 4메가바이트

어떤 답이 맞습니까?

다음, B :

내가 태그가 블록의 수를 추가하여 계산 플러스 오프셋, 플러스 인덱스 있다고 생각하는 방법을 계산하는 부분 B.의 확신입니다. 이것은 4 방향 세트 연관이므로 각 세트에 4 개의 블록이 있습니다. 기본 인덱스 크기가 10 비트이고 4 방향 세트 연관이기 때문에 인덱스가 2 씩 감소하므로 인덱스는 8 비트입니다. 그러나 태그를 계산하는 데 도움이되는 오프셋을 계산하는 방법을 알지 못합니다.

모든 도움을 주시면 감사하겠습니다.

답변

5

파트 a에 대해 두 가지 오류가있었습니다. 첫째, 질문은 특별히 "페이지 테이블 항목은 4 바이트로 올림됩니다"라고 명시했습니다. 둘째로, PTE는 페이지가 정렬되는 주소를 기준으로 실제 주소 인을 결정하는 데 필요한 비트를 포함합니다. 설명 된 시스템에서 실제 주소는 30 비트 (1 GiB)에 불과합니다.이 시스템은 4KB 페이지를 사용하기 때문에 PTE의 실제 주소 중 최하위 12 비트는 모두 0이므로 암시 적이 될 수 있습니다. 따라서 물리적 주소의 경우 18 비트 (30-12)가 필요합니다.

대부분의 PTE에는 2 바이트의 제곱으로 반올림하는 것이 바람직하지만, 유효 비트, 수정 된 비트, 액세스 된 비트 및 사용자 및 감독자 모드의 사용 권한 비트와 같은 추가 데이터가 포함됩니다. 따라서 512 MiB의 물리적 주소 공간과 8 KiB 페이지 (물리적 주소를 나타내는 데 필요한 16 비트)가 있더라도 2 바이트 PTE를 사용할 수 없습니다.

(32 비트 프로세서는 플랫 페이지 테이블을 사용하지 않음에 유의해야합니다.) 32 비트 주소의 경우 일반적으로 계층 적 또는 선형 페이지 테이블이 사용되며 전체 점유에 약간의 공간 오버 헤드가 발생하므로 부분적 점유 및 고밀도 할당의 경우 일반적으로 적은 메모리를 사용하지만 대부분의 프로세서는 각 프로세스가 고유 한 페이지 테이블을 갖는 다중 주소 공간 OS 용으로 설계 되었기 때문에 특히 중요합니다. 페이지 테이블의 물리적 메모리 [400 MiB]의 절반만으로도 100 개의 프로세스를 지원할 수 있습니다.)

파트 b의 경우 4 방향 세트 연관이라는 것은 각 세트에 4 개의 블록이 있다는 것을 의미합니다. 따라서 엔트리 수에 따라 인덱싱에 필요한 비트 수에서 2 비트가 뺍니다. 그러나 log2 (256)는 10이 아닌 8이므로 8 비트 만 TLB를 인덱싱하는 데 사용됩니다.

데이터 캐시에서 태그 크기는 주소 비트 수에서 인덱스 비트 수를 뺀 값 (캐시 블록 내의 오프셋 비트 수 빼기)과 같습니다.

TLB의 경우 가상 주소는 페이지 크기에 정렬됩니다 (페이지 내의 최하위 비트는 변환되지 않습니다). 4 KiB 페이지의 경우 이것은 12 개의 최하위 비트가 무시된다는 것을 의미합니다. 32 비트 가상 주소를 사용하면 20 비트가 남습니다.

이러한 비트 중 6 개가 이미 색인 생성에 사용되었으므로 14 비트가 남습니다.

클러스터되지 않은 TLB의 경우 각 태그는 하나의 변환과 연결됩니다. 이는 1 바이트의 데이터 캐시 블록 크기 (즉, 0 오프셋 비트)와 동일 할 것이다. 따라서 태그 (주소 공간 ID 제외)는 14 비트가됩니다.

(클러스터 된 TLB [섹터 캐시 블록과 유사]에서 각 "항목"에 대해 두 개 이상의 번역이 제공됩니다. 항목이 번역 항목 또는 태그 및 해당 태그와 관련된 여러 번역본이 포함되어 있습니다. [이러한 문제가 이러한 복잡성의 일부가 아니라고 생각합니다.]

+0

의견을 보내 주셔서 대단히 감사드립니다. 나는 파트 b를 완전히 이해합니다. 나는 부분적으로 나의 실수에 대한 당신의 설명에 약간 혼란 스럽다. 페이지 테이블의 항목 수를 계산하지 않습니까? – basil

+0

@basil 아니요, 가정 된 플랫 페이지 테이블의 경우 필요한 PTE 수에 대해서는 정확하지만 문제의 명시된 가정과 실제 표현에 필요한 비트 수 모두에서 PTE 당 비트 수가 잘못되었습니다. 페이지의 주소. (플랫 페이지 테이블은 극히 드물다는 것을 언급했는데, 그 의미에서 페이지 테이블의 크기는 정확하지 않겠지 만, 이는 문제의 가정이 이해되지 않은 문제입니다.) –

+0

나는 당신을 생각합니다. 따라서 위의 실제 주소에 대한 설명에 따라 입력 크기가 18 비트가 될 것이라고 말하고 있습니까? 그리고 나서 이것은 페이지 테이블에 대한 계산에 영향을 미칩니다 (정확한 계산 방법은 무엇입니까?). 반올림 페이지 테이블 항목에 대한 비트 여전히 날 던져,이 영향을 전체 크기, 항목 크기 및 페이지 테이블 항목 수를? – basil