페이지 테이블 워크가 캐시됩니까?


12

TLB 미스가 발생하고 프로세서가 페이지 테이블을 걷고있는 경우 하드웨어 TLB 관리 (예 : Intel x86-64)가있는 마이크로 프로세서에서 이러한 (오프 칩) 메모리 액세스는 캐시 계층 (L1, L2 등)을 통과합니다. )?


전자 디자인과 관련이 없습니다. 질문이 마감됩니다.
레온 헬러

8
특정 칩의 작동 방식을 묻기 때문에 주제에 관한 것 같습니다.
Olin Lathrop

5
@OlinLathrop : 동의합니다 : 집적 회로의 저수준 세부 사항이 주제라고 생각합니다.
davidcary

프로세서 기능을 디버깅하는 것이 결정 론적 시스템을 설계하는 데있어 중요한 단계라는 데 동의해야합니다. 이것은 우리의 경계 중 하나에 가까워지고 있지만 내부는 강력하게 보입니다.
Kortuk

답변:


8

그렇습니다. Intel x86-64 프로세서에서 TLB 미스가 발생하고 프로세서가 페이지 테이블을 걷고있을 때 이러한 오프 칩 메모리 액세스는 캐시 계층을 통과합니다.

나는 아직도 약간의 세부 사항에 대해 약간 애매 모호하며 다른 답변이 그것들을 채울 것이라고 희망합니다. 내 이해는 :

  • 일부 주소 레지스터의 가상 주소는 먼저 빠른 TLB로 전달되어 실제 주소로 변환됩니다. PC의 주소는 L1 ITLB로 전달되고 다른 레지스터의 주소는 L1 DTLB로 전달됩니다. .
  • 첫 번째 조회가 누락되면 더 느리고 더 큰 TLB가 시도됩니다. (이 L2 TLB가 ITLB와 DTLB로 분리 되었습니까? 아니면 통합 TLB 캐시입니까? TLB 레벨이 더 있습니까? L3? L4?
  • TLB 조회가 완전히 실패하고 x86 및 x86-64 VHPT 워커가 비활성화 된 경우, CPU는 OS 커널에 의해 인터셉트 된 TLB 누락 오류를 알립니다. 내 이해는 실제로 모든 비 x86 CPU가 동일한 작업을 수행한다는 것입니다. 소프트웨어에서 TLB 미스를 완전히 처리합니다. 활성화 된 경우 x86 및 x86-64 프로세서에는 다음 몇 단계를 처리하는 하드웨어 지원 VHPT 테이블 워커가 있습니다. (x86 및 x86-64 칩에는 VHPT를 완전히 비활성화하는 하나의 비트가 있거나 일부 주소 범위에 대해 VHPT를 활성화하고 다른 주소 범위에 대해 VHPT를 비활성화 할 수있는 비트가 있습니까? 해당 비트는 어디에 있습니까?)
  • TLB 조회가 완전히 실패하면 원래 (아마도 사용자 모드) 가상 주소 V1이 V1의 실제 페이지 번호를 보유하는 페이지 테이블 항목 PTE의 가상 주소 인 V2로 변환됩니다.
  • V2는 다시 가상 주소이므로 CPU는 L1을 건너 뛰고 L2로 바로 이동하는 것을 제외하고 일반적인 가상-물리 주소 변환을 거칩니다.
  • 하드웨어는 (가상 색인화 된) L2 캐시에서 해당 PTE를 가져 오는 것과 동시에 TLB에서 가상 주소 V2를 찾습니다.
  • V2는 명령어의 주소가 아니기 때문에 L1 명령어 캐시를 거치지 않습니다. V2는 일반 사용자 데이터의 주소가 아니기 때문에 L1 데이터 캐시를 거치지 않습니다. V2는 초기에 L2 통합 캐시 (통합 명령 + 데이터 + PTE 캐시)로 공급됩니다. "캐시 계층 구조 예제"를 참조하십시오 .
  • L2 캐시 (또는 L3 또는 다른 가상 인덱스 캐시)에 PTE가 포함 된 경우 VHPT는 캐시 메모리에서 PTE를 가져 와서 TLB에 V1 용 PTE를 설치하고 해당 PTE의 물리적 주소는 원래 가상 주소 V1을 실제 RAM 주소로 가져 오면 결국 OS의 도움없이 해당 데이터 나 명령을 하드웨어로 완전히 가져옵니다.
  • 가상 색인 캐시의 모든 레벨이 실패하지만 V2에 대해이 두 번째 TLB 조회에 성공하면 VHPT는 물리적 색인 캐시 또는 기본 메모리에서 PTE를 페치하고 V1에 대한 PTE를 TLB에 설치하고 해당 물리적 ​​주소는 PTE는 원래 가상 주소 V1을 실제 RAM 주소로 변환하는 데 사용되며 결국 OS의 도움없이 해당 데이터 또는 명령을 하드웨어에서 완전히 가져옵니다.
  • 이 두 번째 TLB 조회가 실패하면 하드웨어 VHPT 워커는 VHPT TRANSLATION FAULT를 포기합니다.
  • VHPT TRANSLATION FAULT가 발생하면 CPU가 OS에 트랩됩니다. OS는 무엇이 잘못되었는지 파악하고 문제를 해결해야합니다.
  • (a) V2를 포함하는 페이지가 현재 디스크로 스왑 아웃되어 OS가 해당 페이지를 RAM으로 읽고 실패한 명령을 다시 시작하거나
  • (b) 버그가있는 프로그램이 유효하지 않은 위치를 읽거나 쓰거나 실행하려고하거나 OS가 프로세스를 종료하거나
  • (c) OS 작성자가이 메커니즘을 사용하여 다양한 종류의 액세스를 포착하기 위해 수행하는 다양한 기타 트릭-디스크로 교체 될 수있는 V1이 포함 된 페이지를로드합니다. 새로운 프로그램을 디버깅하는 데 사용되는 다양한 트랩; 직접 지원하지 않는 CPU에서 "W ^ X"를 시뮬레이션합니다. COW (Copy-On-Write) 지원 기타

Thomas W. Barr, Alan L. Cox, Scott Rixner의 2 페이지에있는 다이어그램. "번역 캐싱 : 건너 뛰지 말고 걷기 (페이지 테이블)" 는 "MMU 캐시에 저장된 항목"과 "L2 데이터 캐시에 저장된 항목"사이에 선을 그립니다. (이것은 "전자 디자인"에 대한 주제 인 새로운 CPU를 디자인 하는 사람들에게 유용한 논문 일 수 있습니다 .)

스테판 에라 니안과 데이비드 모스 버거. "IA-64 Linux 커널의 가상 메모리" 및 Ulrich Drepper. "무엇 모든 프로그래머가 메모리에 대해 알아야한다" (이것은 운영 체제를 쓰는 사람들을위한 유용한 종이 될 수 약간 주제에서 벗어난 ED에 대한 인 IA-64 페이지 테이블과 거래 -와 아마 스택 오버플로를 "operating- system "태그 또는 "osdev "태그 또는 OSDev.org 위키 가 해당 주제에 더 적합한 위치입니다).

Intel의 533 페이지에있는 표 A-10. "Intel® 64 및 IA-32 아키텍처 소프트웨어 개발자 매뉴얼" "PAGE_WALKS.CYCLES ... 대부분의 페이지 워크가 캐시에 의해 만족되는지 또는 L2 캐시 미스를 유발하는지 여부를 암시 할 수 있습니다."


나는 그 대답을 좋아하지만, 아마도 가치있는 공감대를주는 것을 편안하게 느끼기 위해 필요한 전문 지식이없는 많은 사람들 중 하나 일 것입니다. 다른 전문가가 확인한대로 이미 획득 한 담당자를 알려 드리겠습니다.
Kortuk

나는 이것이 옳지 않다고 생각합니다. TLB 조회에 대한 글 머리 기호 1 + 2는 올바른 AFAICT이지만 3은 그렇지 않습니다. x86 (또는 x86-64)의 페이지 테이블 워크는 소프트웨어에서 처리되지 않으며 (예외가 적용되며 나중에 참조) 하드웨어에서 처리됩니다. 즉, CPU가 TLB를 사용하여 주소를 확인할 수 없다고 판단하면 CR3 레지스터가 가리키는 테이블에서 시작하여 페이지 테이블을 스스로 이동합니다. 이 해결에 실패한 경우에만 CPU의 페이지 결함 핸들러를 호출합니다. 특정 모드에서 하이퍼 바이저가 게스트에서 발생하는 페이지 결함을 해결하는 가상화 확장은 예외입니다.
Morty

x86에 소프트웨어 TLB 업데이트를 수행하는 방법이 없다고 생각합니다. soft-TLB 처리를 허용하는 ISA에는 SW가 TLB 항목을 수정하는 특별한 지침이 있지만 x86에는 invlpg주어진 virt addr에 대한 TLB 캐싱을 무효화하는 것 외에는 그렇지 않다고 생각 합니다. HW pagewalk에서 해당 가상 주소에 대한 항목을 찾지 못하거나 해당 항목의 권한이 액세스를 허용하지 않으면 #PF예외 가 발생합니다. OS는 페이지 테이블을 업데이트하여 (디스크에서 데이터를 페이징 한 후 또는 기록 중 복사를 수행 한 후) 페이지로드를 업데이트 한 다음 다시 시작하여 결함이있는로드 / 스토어가 다시 실행되고 HW 페이지 워크가 성공합니다.
Peter Cordes


4

나는 이것이 전자 스택 교환이 아니라 컴퓨터 아키텍처 스택 교환에 속하지만 여기에 있기 때문에 동의합니다.

@davidcary가 맞습니다.

일부 역사 :

Intel x86 페이지 테이블 워크는 Pentium이라고하는 P5까지 캐시되지 않았습니다. 보다 정확하게는 페이지 테이블 워크 메모리 액세스가 캐시되지 않고 캐시를 무시합니다. 그 때까지 대부분의 컴퓨터는 연속 기입이므로 캐시와 일치하는 값을 받았습니다. 그러나 그들은 캐시를 스누핑하지 않았습니다.

P6, 일명 Pentium Pro 및 AFAIK는 모든 후속 프로세서 페이지 테이블 워크에서 캐시에 액세스하고 캐시에서 가져온 값을 사용할 수있었습니다. 따라서, 그들은 다시 쓰기 캐시로 작업했습니다. (물론 MTRR 등으로 정의 된 캐시 할 수없는 메모리에 페이지 테이블을 배치 할 수 있습니다. 그러나 OS 디버깅에 유용 할 수 있지만 성능이 크게 저하됩니다.)

그런데,이 "페이지 테이블 워크 메모리 액세스는 데이터 캐시에 액세스 할 수있다"는 "페이지 테이블 엔트리는 TLB 변환 Lookaside 버퍼에 저장 (캐싱) 될 수있다"와는 별개이다. 일부 컴퓨터에서는 TLB를 "번역 캐시"라고합니다.

또 다른 관련 문제는 페이지 테이블의 내부 노드가 더 많은 TLB와 유사한 데이터 구조, 예를 들어 PDE 캐시에 캐시 될 수 있다는 것입니다.

한 가지 중요한 차이점은 데이터 캐시가 일관되고 스누핑 된 것입니다. 그러나 TLB 및 PDE 캐시는 스누핑되지 않으며, 즉 일관성이 없습니다. 결론은 페이지 테이블이 비 일관성 TLB 및 PDE 캐시 등으로 캐시 될 수 있기 때문에 페이지 테이블 항목이있을 때 소프트웨어가 개별 항목 또는 벌크 그룹 (예 : 전체 TLB)을 명시 적으로 플러시해야한다는 것입니다. 캐시가 변경되었습니다. RW-> R-> I에서 이동하거나 주소를 변경하는 "위험한"방식으로 변경 한 경우.

새로운 유형의 비 일관성 TLB와 같은 캐싱이 추가 될 때마다 일부 OS는 작동하지 않았다는 암시적인 가정이 있었기 때문에 고장이 났다고 말할 수 있습니다.


새로운 comp. 아치. 이 제안 은 "3 개월 전"에 시작되었습니다. 나는 그것이 영역을 벗어나지 못한 초기의 것이 있다고 생각합니다 (충분한 추종자?).
Paul A. Clayton 22
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.