L1 및 L2 캐시의 라인 크기
이 포럼 의 이전 질문 에서 저는 대부분의 메모리 시스템에서 L1 캐시가 L2 캐시의 하위 집합이라는 것을 알게되었습니다. 즉, L2에서 제거 된 항목은 L1에서도 제거된다는 것을 의미합니다.
이제 내 질문은 L2 캐시의 항목에 대해 L1 캐시의 해당 항목을 어떻게 결정합니까? L2 항목에 저장된 유일한 정보는 태그 정보입니다. 이 태그 정보를 기반으로 addr를 다시 생성하면 L1 및 L2 캐시의 라인 크기가 동일하지 않으면 L1 캐시에서 여러 줄에 걸쳐있을 수 있습니다.
아키텍처가 두 라인을 모두 플러시하는 데 정말로 신경 쓰거나 동일한 라인 크기로 L1 및 L2 캐시를 유지합니다.
이것이 정책 결정이라는 것을 이해하지만 일반적으로 사용되는 기술을 알고 싶습니다.
코어 i7에서 L1, L2 및 L3의 라인 크기는 동일합니다. 즉 64 바이트입니다. 나는 이것이 포괄적 인 속성과 일관성을 유지하는 것을 단순화한다고 생각한다.
28 페이지 참조 : https://www.scss.tcd.ie/Jeremy.Jones/CS3021/5%20caches.pdf
Cache-Lines 크기는 (일반적으로) 64 바이트입니다.
또한 프로세서 캐시에 대한 매우 흥미로운 기사를 살펴보십시오. 프로세서 캐시 효과 갤러리
다음 장을 찾을 수 있습니다.
- 메모리 액세스 및 성능
- 캐시 라인의 영향
- L1 및 L2 캐시 크기
- 명령어 수준 병렬 처리
- 캐시 연관성
- 잘못된 캐시 라인 공유
- 하드웨어 복잡성
엄격하게 포함 된 캐시 계층 구조에서 캐시 블록 크기를 처리하는 가장 일반적인 기술은 포함 속성이 적용되는 모든 수준의 캐시에 대해 동일한 크기의 캐시 블록을 사용하는 것입니다. 이로 인해 상위 레벨 캐시가 더 큰 블록을 사용하는 경우보다 태그 오버 헤드가 더 커지며, 이는 칩 영역을 사용할뿐만 아니라 상위 레벨 캐시가 일반적으로 단계적 액세스 (데이터 부분에 액세스하기 전에 태그를 확인 함)를 사용하기 때문에 지연 시간을 증가시킬 수도 있습니다. 그러나 이는 또한 설계를 다소 단순화하고 데이터의 미사용 부분에서 낭비되는 용량을 줄입니다. 추가 32 비트 태그의 영역 패널티를 보상하기 위해 128 바이트 캐시 블록에서 사용되지 않은 64 바이트 청크의 많은 부분을 차지하지 않습니다. 또한 비교적 간단한 프리 페칭을 통해 더 넓은 공간적 지역성을 활용하는 더 큰 캐시 블록 효과를 제공 할 수 있습니다.
덜 일반적인 기술은 캐시 블록을 섹터로 나눕니다. 하위 수준 캐시에 대한 블록 크기와 동일한 섹터 크기를 사용하면 상위 수준 캐시의 각 섹터에 자체 유효 비트가 있기 때문에 과도한 역 무효화 문제를 방지 할 수 있습니다. (단순한 유효성이 아닌 각 섹터에 대한 모든 일관성 상태 메타 데이터를 제공하면 블록의 하나 이상의 섹터가 더티 / 수정되지 않았을 때 과도한 쓰기 저장 대역폭 사용을 피할 수 있으며 일부 일관성 오버 헤드 (예 : 한 섹터가 공유 상태이고 다른 섹터가 단독 상태에서 단독 상태의 섹터에 대한 쓰기는 일관성 트래픽을 포함하지 않을 수 있습니다 (디렉터리 일관성이 아닌 스누피가 사용되는 경우).
섹터 화 된 캐시 블록으로 인한 면적 절약은 태그가 프로세서 칩에 있지만 데이터가 오프 칩일 때 특히 중요했습니다. 분명히 데이터 스토리지가 프로세서 칩의 크기와 비슷한 영역을 차지한다면 (불합리하지 않은) 64 바이트 블록이있는 32 비트 태그는 프로세서 영역의 약 16 분의 1 (~ 6 %)을 차지하는 반면 128- 바이트 블록은 절반을 차지합니다. (2009 년에 출시 된 IBM의 POWER6 +는 아마도 온 프로세서 칩 태그와 오프 프로세서 데이터를 사용하는 가장 최신 프로세서 일 것입니다. IBM처럼 고밀도 임베디드 DRAM에 데이터를 저장하고 저밀도 SRAM에 태그를 저장하면이를 과장합니다. 효과.)
인텔은 더 작은 단위를 나타내는 "캐시 라인"과 큰 단위를 나타내는 "캐시 섹터"를 사용합니다. (이것이 제가 설명에서 "캐시 블록"을 사용한 이유 중 하나입니다.) 인텔의 용어를 사용하면 레벨이 엄격하게 포함되었는지, 엄격하게 배타적 이었는지 또는 사용되었는지 여부에 관계없이 캐시 라인의 크기가 캐시 수준에 따라 달라지는 것은 매우 드문 일입니다. 다른 포함 정책.
(엄격한 제외는 일반적으로 하위 수준 캐시의 제거가 상위 수준 캐시에 삽입되는 희생 캐시로 상위 수준 캐시를 사용합니다. 분명히 블록 크기가 다르고 섹터 링을 사용하지 않은 경우 제거에는 나머지 캐시가 필요합니다. 큰 블록 어딘가로부터 판독 할 및 [경우 하위 레벨 캐시에 존재. 무효화 이론적 L1 퇴거가 L2 우회 L3와 L1 / L2 캐시 미스에 갈 것이다 전용 될 경우, 엄격한 배제가 풀릴 캐시 우회하여 사용될 수있다 할당 중 L1 또는L2, 특정 액세스에 대해 L1을 우회합니다. 내가 아는이 구현에 가장 가까운 것은 Itanium이 부동 소수점 액세스를 위해 L1을 우회하는 것입니다. 그러나 정확하게 기억하면 L2에는 L1이 포함되어 있습니다.])
일반적으로 주 메모리에 대한 한 번의 액세스에서 64 바이트의 데이터와 8 바이트의 패리티 / ECC (정확히 기억하지 못함)가 액세스됩니다. 그리고 다양한 메모리 레벨에서 다른 캐시 라인 크기를 유지하는 것은 다소 복잡합니다. 캐시 라인 크기는 다른 어떤 것보다 해당 아키텍처의 단어 정렬 크기와 더 관련이 있다는 점에 유의해야합니다. 이를 기반으로 캐시 라인 크기는 메모리 액세스 크기와 다를 가능성이 거의 없습니다. 이제 패리티 비트는 메모리 컨트롤러 용이므로 캐시 라인 크기는 일반적으로 64 바이트입니다. 프로세서는 실제로 레지스터 너머를 거의 제어하지 않습니다. 컴퓨터에서 진행되는 다른 모든 작업은 CPU 성능을 최적화하기 위해 하드웨어를 도입하는 것입니다. 그런 의미에서도
참고 URL : https://stackoverflow.com/questions/14707803/line-size-of-l1-and-l2-caches
'UFO ET IT' 카테고리의 다른 글
| 두 개의 버튼이 다른 버튼 위에있는 프로그래밍 방식으로 RelativeLayout을 만드는 방법은 무엇입니까? (0) | 2020.11.19 |
|---|---|
| CSS 테이블 td 너비-고정, 유연하지 않음 (0) | 2020.11.19 |
| URL 인코딩 된 URL에 추가 할 구문 분석 문자열 (0) | 2020.11.19 |
| 여러 작업을 실행하는 Gradle 사용자 지정 작업 (0) | 2020.11.19 |
| 전역 변수를 사용하지 않고 다른 함수의 변수에 액세스 (0) | 2020.11.19 |