L1, L2 및 L3에서 캐싱하기 위해 x86/x86_64 프로세서에서 실제 또는 가상 주소 지정이 사용됩니까?

Question

L1, L2 및 L3 (LLC)에서 캐싱하기 위해 x86/x86_64 프로세서에서 물리적/가상 (PT/PTE 및 TLB 사용)으로 어떤 주소 지정을 사용하며 어떤 방식으로 PAT(page attribute table)이 영향을 줍니까?

이 경우 드라이버 (커널 공간)와 응용 프로그램 (사용자 공간)간에 차이가 있습니까?

Answer 1

귀하의 질문에 대한 답변은 - 다릅니다. 이것은 엄격하게 CPU 설계 결정이며, 성능과 복잡성 간의 균형을 유지합니다.

최근 인텔 코어 프로세서를 예로 들어 보겠습니다. 물리적으로 태그를 지정하고 가상으로 인덱싱합니다 (최소한 http://www.realworldtech.com/sandy-bridge/7/에 따라). 이것은 캐시가 순수한 물리적 주소 공간에서만 조회를 완료하여 라인이 있는지 여부를 결정할 수 있음을 의미합니다. 그러나 L1은 32k, 8-way associative이므로 64 세트를 사용하므로 올바른 세트를 찾기 위해 6 비트에서 11 비트까지 주소 지정 만하면됩니다. 가상 주소와 실제 주소는이 범위에서 동일하므로 캐쉬 세트를 읽는 것과 동시에 DTLB를 탐색 할 수 있습니다 (알려진 설명은 -을 참조하십시오).

이론적으로 주소 변환 (TLB 조회 및 TLB 누락의 경우 페이지 이동)을 거치지 않아도되는 사실상의 색인 + 가상 태그가 지정된 캐시를 작성할 수 있습니다. 그러나 이는 특히 메모리 앨리어싱과 같은 여러 문제를 야기합니다. 두 개의 가상 주소가 동일한 물리적 주소에 매핑되는 경우입니다.

코어 1은 이러한 가상 캐시 (사실상 addr C에 매핑되지만 아직이 검사를 수행하지 않았습니다)에 가상 어드 레스 캐시를 가지고 있습니다. core2는 동일한 addr C에 매핑되는 virtual addr B에 기록합니다. 즉, core1에서 해당 라인을 이동 및 무효화하고 데이터 병합 및 일관성 관리를 관리하는 메커니즘 (보통 "snoop", Jim Goodman이 작성한 용어)이 필요합니다. 필요한 경우. 그러나 core1은 가상 주소록 B에 대해 알지 못하고 가상 주소록에 실제 주소 C를 저장하지 않기 때문에 해당 스눕에 응답 할 수 없습니다. 따라서 우리는 문제가 있음을 알 수 있습니다. 이것은 엄격한 x86 시스템과 관련이 있지만, 다른 아키텍처는 더 느슨하고 그러한 캐시를 더 간단하게 관리 할 수 ​​있습니다.

다른 질문에 관해서는 - 제가 생각할 수있는 PAT와 실제 연결이 없습니다. 캐시는 이미 설계되었으며 다른 메모리 유형에 대해 변경할 수 없습니다. 다른 질문에 대해서도 같은 대답 - HW는 주로 사용자/커널 모드 (보안 검사를 위해 제공되는 메커니즘을 제외하고는 주로 다양한 링)의 구별 아래에 있습니다.