Linux의 캐시 메모리에 대하여(상세 그림 및 텍스트 설명)

리눅스의 캐시 메모리에 대하여 캐시 메모리(자세한 그림 및 텍스트 설명)

오늘 탐구 주제는 캐시입니다. 우리는 몇 가지 질문을 중심으로 돌아갑니다. 캐시가 왜 필요한가요? 캐시에 데이터 적중 여부를 확인하는 방법은 무엇입니까? 캐시 유형은 무엇이며 차이점은 무엇입니까?

캐시 메모리가 필요한 이유

캐시가 무엇인지 생각하기 전에 먼저 첫 번째 질문인 프로그램이 어떻게 실행되는지 생각해 봅시다. 프로그램은 RAM에서 실행되며 RAM은 흔히 DDR(DDR3, DDR4 등)이라고 부르는 것입니다. 우리는 이를 메인 메모리라고 부릅니다. 프로세스를 실행해야 할 때 먼저 플래시 장치(예: eMMC, UFS 등)에서 실행 가능한 프로그램을 메인 메모리로 로드한 다음 실행을 시작합니다. CPU 내부에는 여러 개의 범용 레지스터(레지스터)가 있습니다. CPU가 변수에 1을 더해야 하는 경우(주소가 A라고 가정) 일반적으로 다음 세 단계로 나뉩니다.

1. CPU는 주소 A의 데이터를 메인 메모리에서 내부 범용으로 읽습니다. x0 레지스터(ARM64 아키텍처의 범용 레지스터 1).

2. 일반 레지스터 x0 + 1.

3. CPU는 일반 레지스터 x0의 값을 메인 메모리에 씁니다.

이 과정을 다음과 같이 표현할 수 있습니다.

실제로는 CPU 일반 레지스터와 메인 메모리의 속도 차이가 큽니다. 둘 사이의 속도 관계는 대략 다음과 같습니다.

CPU 레지스터의 속도는 일반적으로 1ns 미만이고, 메인 메모리의 속도는 일반적으로 약 65ns입니다. 속도 차이는 거의 백 배에 달합니다. 따라서 위 예의 세 단계 중 1단계와 3단계는 실제로 매우 느립니다. CPU가 메인 메모리로부터 작업을 로드/저장하려고 할 때, CPU는 메인 메모리의 속도 제한으로 인해 이렇게 긴 65ns를 기다려야 합니다. 주 메모리의 속도를 높일 수 있다면 시스템 성능이 크게 향상될 것입니다.

오늘날의 DDR 저장 장치는 쉽게 수 GB를 가질 수 있는데, 이는 매우 큰 용량입니다. 더 빠른 재료를 사용하여 더 빠른 주 메모리를 만들고 거의 동일한 용량을 갖는다면. 비용이 크게 증가합니다. 우리는 비용이 매우 낮을 것으로 예상하면서 메인 메모리의 속도와 용량을 높이려고 노력하고 있는데 이는 다소 당황스럽습니다. 따라서 우리는 매우 빠르지만 용량이 매우 작은 저장 장치를 만드는 절충 방법을 가지고 있습니다. 그러면 비용이 너무 높지 않을 것입니다. 우리는 이것을 저장 장치 캐시 메모리라고 부릅니다.

하드웨어적인 측면에서는 메인 메모리 데이터의 캐시로 CPU와 메인 메모리 사이에 캐시를 배치합니다. CPU가 메인 메모리로부터 데이터를 로드/저장하려고 시도할 때, CPU는 먼저 캐시에서 해당 주소의 데이터가 캐시에 캐시되어 있는지 확인합니다. 데이터가 캐시에 캐시되어 있으면 캐시에서 직접 데이터를 가져와 CPU로 반환합니다. 캐시가 있는 경우 위의 예에서 프로그램이 실행되는 과정은 다음과 같습니다.

CPU와 메인 메모리 간 직접 데이터 전송 방식이 CPU와 메인 메모리 간 직접 데이터 전송 방식으로 전환됩니다. 캐시. 캐시는 메인 메모리와 메인 메모리 사이의 데이터 전송을 담당합니다.

다단계 캐시 메모리

캐시 속도도 시스템 성능에 어느 정도 영향을 미칩니다.

일반적으로 캐시 속도는 1ns에 도달할 수 있으며 이는 CPU 레지스터 속도와 거의 비슷합니다. 하지만 이것이 사람들의 성과 추구를 만족시킬 수 있을까요? 설마. 원하는 데이터가 캐시에 캐시되지 않은 경우에도 메인 메모리에서 데이터를 로드하려면 오랜 시간을 기다려야 합니다. 성능을 더욱 향상시키기 위해 다중 레벨 캐시가 도입되었습니다.

앞서 언급한 캐시를 L1 캐시(1단계 캐시)라고 합니다. L1 캐시 뒤에 L2 캐시를 연결하고, L2 캐시와 메인 메모리 사이에 L3 캐시를 연결합니다. 레벨이 높을수록 속도는 느려지고 용량은 커집니다. 하지만 메인 메모리에 비하면 속도는 여전히 매우 빠릅니다. 다양한 수준의 캐시 속도 간의 관계는 다음과 같습니다.

레벨 3 캐시의 버퍼링 이후 각 수준의 캐시와 주 메모리 간의 속도 차이도 점차 감소합니다. 실제 시스템에서 모든 수준의 캐시 간 하드웨어는 어떻게 관련되어 있습니까? Cortex-A53 아키텍처의 모든 수준에서 캐시 간의 하드웨어 추상화 블록 다이어그램을 다음과 같이 살펴보겠습니다.

Cortex-A53 아키텍처에서는 L1 캐시가 별도의 명령어 캐시(ICache)와 데이터 캐시(DCache)로 구분됩니다. L1 캐시는 CPU 전용이며 각 CPU에는 L1 캐시가 있습니다. 클러스터의 모든 CPU는 L2 캐시를 공유합니다. L2 캐시는 명령과 데이터를 구분하지 않으며 둘 다 캐시할 수 있습니다. L3 캐시는 모든 클러스터에서 공유됩니다. L3 캐시는 버스를 통해 메인 메모리와 연결됩니다.

다단계 캐시 간의 협력

먼저 두 가지 명사 개념인 히트(Hits)와 미스(Miss)를 소개합니다. CPU가 접근하려는 데이터가 캐시에 캐시되는 것을 '히트(hit)'라고 하고, 그 반대의 경우를 '미스(miss)'라고 합니다. 다중 레벨 캐시는 어떻게 함께 작동합니까? 고려 중인 시스템에는 두 가지 수준의 캐시만 있다고 가정합니다.

CPU는 특정 주소에서 데이터를 로드하려고 할 때 먼저 L1 캐시에서 적중이 있는지 확인하고 적중되면 해당 데이터를 CPU로 반환합니다. L1 캐시가 누락된 경우 L2 캐시에서 계속 검색하세요. L2 캐시에 도달하면 데이터가 L1 캐시와 CPU로 반환됩니다. L2 캐시도 없으면 아쉽게도 메인 메모리에서 데이터를 로드하고 해당 데이터를 L2 캐시, L1 캐시 및 CPU로 반환해야 합니다. 이러한 다단계 캐시 작업 방식을 포괄적 캐시라고 합니다.

특정 주소의 데이터는 다중 레벨 캐시에 존재할 수 있습니다. 포괄적 캐시에 해당하는 것은 독점 캐시입니다. 이는 특정 주소의 데이터 캐시가 다중 레벨 캐시의 한 레벨에만 존재하도록 보장합니다. 즉, 어떤 주소의 데이터도 L1 캐시와 L2 캐시에 동시에 캐시할 수 없습니다.

직접 매핑된 캐시

캐시 관련 용어를 계속 소개합니다. 캐시의 크기를 캐시 크기라고 하며, 이는 캐시가 캐시할 수 있는 최대 데이터의 크기를 나타냅니다. 캐시를 동일한 여러 개의 블록으로 나누고, 각 블록의 크기를 캐시 라인이라고 하며, 그 크기는 캐시 라인 크기입니다.

예를 들어 64바이트 크기의 캐시입니다. 64바이트를 64개의 블록으로 균등하게 나누면 캐시 라인은 1바이트가 되고 총 64개의 캐시 라인이 있습니다. 64바이트를 8개의 블록으로 균등하게 나누면 캐시 라인은 8바이트가 되어 총 8개의 캐시 라인이 됩니다. 현재 하드웨어 설계에서 일반적인 캐시 라인 크기는 4-128바이트입니다. 왜 1바이트가 없나요? 그 이유는 나중에 논의될 것입니다.

여기서 한 가지 주의할 점은 캐시 라인은 캐시와 메인 메모리 사이의 데이터 전송의 가장 작은 단위라는 것입니다. 그것은 무엇을 의미합니까? CPU가 1바이트의 데이터를 로드하려고 할 때 캐시가 누락된 경우 캐시 컨트롤러는 캐시 라인 크기의 데이터를 메인 메모리에서 캐시로 즉시 로드합니다. 예를 들어, 캐시 라인 크기는 8바이트입니다. CPU가 1바이트를 읽어도 캐시가 누락된 후 캐시는 메인 메모리에서 8바이트를 로드하여 전체 캐시 라인을 채웁니다. 그리고 왜? 내가 얘기를 다 하고 나면 이해하게 될 거예요.

다음 설명은 64바이트 캐시에 대한 것이며 캐시 라인 크기는 8바이트라고 가정합니다. 이 캐시는 배열로 간주할 수 있습니다. 배열에는 총 8개의 요소가 있고 각 요소의 크기는 8바이트입니다. 아래 그림과 같습니다.

이제 CPU가 주소 0x0654에서 바이트를 읽습니다. 캐시 컨트롤러는 데이터가 캐시에 있는지 어떻게 결정합니까? 캐시 크기는 주 메모리에 비해 작습니다. 따라서 캐시는 주 메모리에 있는 데이터의 아주 작은 부분만 캐시할 수 있어야 합니다. 주소를 기반으로 제한된 크기의 캐시에서 데이터를 어떻게 찾나요? 현재 하드웨어에서 취하는 접근 방식은 주소를 해시하는 것입니다(주소 모듈로 연산으로 이해될 수 있음). 다음에는 어떻게 진행되는지 볼까요?

총 8개의 캐시 라인이 있으며, 캐시 라인 크기는 8바이트입니다. 따라서 주소의 하위 3비트(위 주소의 파란색 부분 참조)를 사용하여 8바이트의 특정 바이트를 주소 지정할 수 있습니다. 마찬가지로 8라인의 캐시 라인을 사용하여 모든 라인을 커버합니다.

특정 줄을 찾으려면 3비트(위 주소의 노란색 부분 참조)가 필요합니다. 이 부분을 인덱스라고 합니다. 이제 우리는 두 개의 서로 다른 주소의 bit3-bit5가 정확히 동일하면 두 주소는 하드웨어 해싱 후에 동일한 캐시 라인을 찾을 것이라는 것을 알고 있습니다. 따라서 캐시 라인을 찾았다는 것은 우리가 접근한 주소에 해당하는 데이터가 이 캐시 라인에 존재할 수도 있지만, 다른 주소에 해당하는 데이터일 수도 있다는 의미일 뿐입니다. 따라서 태그 배열 영역을 소개하며, 태그 배열과 데이터 배열이 1:1로 대응됩니다.

각 캐시 라인은 고유한 태그에 해당합니다. 태그에 저장되는 것은 전체 주소에서 인덱스와 오프셋에 사용된 비트를 뺀 나머지 비트 너비입니다(위 그림에서 주소의 녹색 부분 참조). 태그, 인덱스 및 오프셋의 조합으로 주소를 고유하게 결정할 수 있습니다. 따라서 주소의 인덱스 비트를 기준으로 캐시 라인을 찾았을 때 현재 캐시 라인에 해당하는 태그를 꺼내어 주소의 태그와 비교하면 캐시 히트를 의미합니다. . 동일하지 않으면 현재 캐시 라인이 다른 주소에 데이터를 저장한다는 의미이며 이는 캐시 미스입니다.

위 그림에서 태그의 값이 0x19인 것을 볼 수 있는데, 이는 주소의 태그 부분과 동일하므로 이 액세스 중에 히트하게 됩니다. 태그 도입으로 인해 이전 질문 중 하나인 "하드웨어 캐시 라인은 왜 1바이트로 만들어지지 않습니까?"라는 답변을 받았습니다. 원래는 8바이트가 태그에 해당했지만 이제는 8개의 태그가 필요하고 많은 메모리를 차지하기 때문에 이로 인해 하드웨어 비용이 증가하게 됩니다.

그림에서 태그 옆에 유효한 비트가 있음을 알 수 있습니다. 이 비트는 캐시 라인의 데이터가 유효한지 여부를 나타내는 데 사용됩니다(예: 1은 유효함을 의미하고 0은 유효하지 않음을 의미함). 시스템이 처음 시작되면 아직 캐시된 데이터가 없기 때문에 캐시에 있는 데이터는 유효하지 않습니다. 캐시 컨트롤러는 유효한 비트를 기반으로 현재 캐시 라인 데이터가 유효한지 여부를 확인할 수 있습니다. 따라서 위의 비교 태그는 캐시 라인 적중 여부를 확인하기 전에 유효한 비트가 유효한지 여부도 확인합니다. 태그 비교는 유효한 경우에만 의미가 있습니다. 유효하지 않은 경우 캐시가 누락된 것으로 직접 판단됩니다.

위의 예에서 캐시 크기는 64바이트이고 캐시 라인 크기는 8바이트입니다. 오프셋, 인덱스, 태그는 각각 3비트, 3비트, 42비트를 사용합니다(주소 너비가 48비트라고 가정). 이제 또 다른 예를 살펴보겠습니다. 캐시 크기는 512바이트, 캐시 라인 크기는 64바이트입니다. 기존의 주소 분할 방식에 따르면 오프셋, 인덱스, 태그는 각각 6비트, 3비트, 39비트를 사용한다. 아래 그림과 같습니다.

직접 매핑 캐시의 장점과 단점

직접 매핑 캐시는 하드웨어 설계가 더 간단하므로 비용이 저렴합니다. 직접 매핑 캐시의 작동 방식에 따라 주 메모리 주소 0x00-0x88에 해당하는 캐시 분포 다이어그램을 그릴 수 있습니다.

0x00-0x3f 주소에 해당하는 데이터가 캐시 전체를 커버할 수 있음을 알 수 있습니다. 주소 0x40-0x7f의 데이터도 전체 캐시를 포함합니다. 이제 한 가지 질문에 대해 생각해 보겠습니다. 프로그램이 0x00, 0x40, 0x80 주소에 순차적으로 액세스하려고 하면 캐시에 있는 데이터는 어떻게 될까요?

우선 0x00, 0x40, 0x80 주소의 인덱스 부분이 동일하다는 점을 이해해야 합니다. 따라서 이 세 주소에 해당하는 캐시 라인은 동일합니다. 따라서 주소 0x00에 액세스하면 캐시가 누락되고 데이터가 주 메모리에서 캐시 라인 0으로 로드됩니다. 0x40 주소에 접근할 때, 우리는 여전히 캐시의 0번째 캐시 라인을 인덱싱합니다. 이때 캐시 라인은 주소 0x00에 해당하는 데이터를 저장하기 때문에 이 시점에서도 캐시는 여전히 누락되어 있을 것입니다. 그런 다음 주 메모리의 0x40 주소 데이터를 첫 번째 캐시 라인에 로드합니다. 같은 방식으로 0x80 주소에 계속 액세스하면 캐시가 여전히 누락됩니다.

이는 매번 메인 메모리에서 데이터를 읽는 것과 같으므로 캐시가 있다고 해서 성능이 향상되는 것은 아닙니다. 주소 0x40에 접근하면 주소 0x00에 캐시된 데이터가 교체됩니다. 이 현상을 캐시 스래싱이라고 합니다. 이 문제를 해결하기 위해 다중 방향 그룹 연결 캐시를 도입합니다. 먼저 가장 간단한 양방향 집합 연결 캐시가 어떻게 작동하는지 살펴보겠습니다.

양방향 설정 연관 캐시

우리는 여전히 캐시 크기가 64바이트이고 캐시 라인 크기가 8바이트라고 가정합니다. 도로의 개념은 무엇입니까? 캐시를 여러 개의 동일한 부분으로 나누고 각 부분은 단방향입니다. 따라서 양방향 세트 연결 캐시는 캐시를 두 개의 동일한 부분으로 나누고 각 부분은 32바이트입니다. 아래 그림과 같습니다.

캐시는 2개의 경로로 나뉘며, 각 경로에는 4개의 캐시 라인이 포함되어 있습니다. 동일한 인덱스를 가진 모든 캐시 라인을 그룹화하여 그룹이라고 부릅니다. 예를 들어, 위 그림에서는 한 그룹에 2개의 캐시 라인이 있어 총 4개의 그룹이 있습니다. 우리는 여전히 0x0654 주소에서 1바이트의 데이터를 읽는다고 가정합니다. 캐시 라인 크기가 8Byte이므로 오프셋에는 3비트가 필요하며 이는 이전 직접 매핑 캐시와 동일합니다. 차이점은 인덱스입니다. 양방향 세트 연결 캐시에서는 한 방향에 캐시 라인이 4개만 있으므로 인덱스에는 2비트만 필요합니다.

위의 예에서는 인덱스(0부터 계산)를 기준으로 두 번째 캐시 라인을 찾습니다. 두 번째 라인은 각각 way 0과 way 1에 해당하는 2개의 캐시 라인에 해당합니다. 따라서 인덱스는 집합 인덱스(그룹 인덱스)라고도 합니다. 먼저 인덱스에 따라 집합을 찾은 후 그룹 내 모든 캐시 라인에 해당하는 태그를 꺼내어 주소의 태그 부분과 비교하면 히트를 의미합니다.

따라서 양방향 설정 연결 캐시와 직접 매핑 캐시의 가장 큰 차이점은 첫 번째 주소에 해당하는 데이터가 2개의 캐시 라인에 해당할 수 있는 반면, 직접 매핑 캐시에서는 하나의 주소만 해당한다는 점입니다. 하나의 캐시 라인으로. 그렇다면 이것의 이점은 정확히 무엇입니까?

양방향 집합 연결 캐시의 장점과 단점

양방향 집합 연결 캐시의 하드웨어 비용은 직접 매핑 캐시보다 높습니다. 태그를 비교할 때마다 여러 캐시 라인에 해당하는 태그를 비교해야 하기 때문입니다(일부 하드웨어는 비교 속도를 높이기 위해 병렬 비교를 수행할 수도 있으며, 이는 하드웨어 설계의 복잡성을 증가시킵니다).

양방향 그룹 연결 캐시가 여전히 필요한 이유는 무엇인가요? 캐시 스래싱 가능성을 줄이는 데 도움이 될 수 있기 때문입니다. 그럼 어떻게 줄어들까요? 양방향 세트 연결 캐시의 작동 방식에 따라 주 메모리 주소 0x00-0x4f에 해당하는 캐시 분포 다이어그램을 그릴 수 있습니다.

직접 매핑된 캐시 섹션에서 "프로그램이 주소 0x00, 0x40, 0x80에 순차적으로 액세스하려고 하면 캐시에 있는 데이터는 어떻게 되나요?"라는 질문을 계속 고려합니다. 이제 주소 0x00의 데이터를 웨이 1에 로드할 수 있고, 0x40을 웨이 0에 로드할 수 있습니다. 이것이 직접 매핑 캐시의 당혹스러운 상황을 어느 정도 피할 수 있습니까? 양방향 설정 연결 캐시의 경우 주소 0x00과 0x40의 데이터가 캐시에 캐시됩니다. 4방향 그룹 연결 캐시를 사용하는 경우 나중에 0x80에 계속 액세스하면 캐시될 수도 있다고 상상해 보세요.

따라서 캐시 크기가 확실한 경우 최악의 경우 그룹 연결 캐시의 성능 향상 효과는 직접 매핑 캐시의 성능 향상과 동일합니다. 대부분의 경우 그룹 연결 캐시의 효과가 더 좋습니다. 직접 매핑된 캐시. 동시에 캐시 스래싱 빈도도 줄어듭니다. 어느 정도 직접 매핑 캐시는 그룹당 하나의 캐시 라인만 있는 집합 연결 캐시의 특별한 경우입니다. 따라서 직접 매핑 캐시는 단방향 집합 연결 캐시라고도 합니다.

전체 연관 캐시

그룹 연관 캐시가 너무 좋으니까, 모든 캐시 라인이 하나의 그룹에 있다면. 성능이 더 좋지 않을까요? 예, 이러한 종류의 캐시는 완전히 연결된 캐시입니다. 우리는 여전히 64바이트 크기의 캐시를 예로 듭니다.

모든 캐시 라인이 하나의 그룹으로 구성되어 있으므로 주소에 인덱스 설정 부분이 필요하지 않습니다. 선택할 수 있는 그룹은 단 하나뿐이므로 간접적으로 선택의 여지가 없음을 의미합니다. 주소의 태그 부분을 모든 캐시 라인에 해당하는 태그와 비교합니다(하드웨어는 병렬 또는 직렬 비교를 수행할 수 있음). 어떤 태그가 같다는 것은 특정 캐시 라인이 적중되었음을 의미합니다. 따라서 완전히 연결된 캐시에서는 모든 주소의 데이터가 모든 캐시 라인에 캐시될 수 있습니다. 따라서 캐시 스래싱 빈도를 최소화할 수 있습니다. 그러나 하드웨어 비용도 더 높습니다.

4방향 집합 연결 캐시 인스턴스 문제

이러한 문제를 고려하면 32KB 크기의 4방향 집합 연결 캐시, 캐시 라인 크기는 32바이트입니다. 다음 질문에 대해 생각해 보세요.

1) 그룹은 몇 개인가요? 2) 주소 폭이 48비트라고 가정하면 인덱스, 오프셋, 태그는 각각 몇 비트를 차지합니까?

총 4개의 채널이 있으므로 각 채널의 크기는 8KB입니다. 캐시 라인 크기는 32Byte이므로 총 256개의 그룹(8KB/32Byte)이 있습니다. 캐시 라인 크기가 32바이트이므로 오프셋에는 5비트가 필요합니다. 총 256개의 그룹이 있으므로 인덱스에는 8비트가 필요하고 나머지는 태그 부분으로 35비트를 차지합니다. 이 캐시는 다음 그림으로 표현될 수 있습니다.

캐시 할당 정책

캐시 할당 정책은 데이터에 캐시 라인을 할당해야 하는 상황을 말합니다. 캐시 할당 전략은 읽기와 쓰기의 두 가지 상황으로 구분됩니다.

읽기 할당:

CPU가 데이터를 읽을 때 캐시 미스가 발생합니다. 이 경우 메인 메모리에서 읽은 데이터를 캐시하기 위해 캐시 라인이 할당됩니다. 기본적으로 캐시는 읽기 할당을 지원합니다.

쓰기 할당:

CPU가 데이터를 쓰고 캐시가 누락된 경우 쓰기 할당 전략이 고려됩니다. 쓰기 할당을 지원하지 않는 경우 쓰기 명령은 주 메모리 데이터만 업데이트한 다음 종료됩니다. 쓰기 할당이 지원되면 먼저 메인 메모리의 데이터를 캐시 라인으로 로드한 다음(읽기 할당을 먼저 수행하는 것과 동일) 캐시 라인의 데이터를 업데이트합니다.

캐시 업데이트 정책(Cache updatepolicy)

캐시 업데이트 정책은 캐시 적중이 발생할 때 쓰기 작업에서 데이터를 업데이트하는 방법을 나타냅니다. 캐시 업데이트 전략은 연속 기입(write-through)과 후기입(write-back)의 두 가지 유형으로 나뉩니다.

Write through:

CPU가 저장 명령을 실행하고 캐시 히트가 발생하면 캐시의 데이터를 업데이트하고 메인 메모리의 데이터를 업데이트합니다. 캐시와 메인 메모리의 데이터는 항상 일관됩니다.

다시 쓰기:

CPU가 저장 명령을 실행하고 캐시에 도달하면 캐시의 데이터만 업데이트됩니다. 그리고 각 캐시 라인에는 데이터가 수정되었는지 여부를 기록하는 더티 비트(더티 비트)라는 비트가 있습니다(이전 그림을 보면 캐시 라인 옆에 D가 있는데, 이는 더티 비트입니다). 더티 비트를 설정하겠습니다. 메인 메모리의 데이터는 캐시 라인이 교체되거나 클린 작업이 수행될 때만 업데이트됩니다. 따라서 주 메모리의 데이터는 수정되지 않은 데이터일 수 있지만 수정된 데이터는 캐시 라인에 있습니다.

그럼, 캐시 라인 사이즈는 왜 캐시 컨트롤러와 메인 메모리 사이의 데이터 전송의 최소 단위인가요? 이는 각 캐시 라인에 더티 비트가 하나만 있기 때문이기도 합니다. 이 더티 비트는 전체 캐시 라인의 수정된 상태를 나타냅니다.

예

64바이트 크기의 직접 매핑 캐시가 있고 쓰기 할당 및 쓰기 메커니즘을 사용하여 캐시 라인 크기가 8바이트라고 가정합니다. CPU가 주소 0x2a에서 바이트를 읽을 때 캐시의 데이터는 어떻게 변경됩니까? 현재 캐시 상태가 아래 그림과 같다고 가정합니다.

인덱스에 따라 해당 캐시 라인을 찾습니다. 해당 태그 부분의 유효한 비트는 합법적이지만 태그 값이 동일하지 않아 삭제가 발생합니다. 이때 주소 0x28에서 캐시 라인으로 8바이트의 데이터를 로드해야 합니다. 그러나 현재 캐시 라인의 더티 비트가 설정되어 있음을 발견했습니다. 따라서 캐시 라인의 데이터를 단순히 버릴 수는 없습니다. write-back 메커니즘으로 인해 캐시에 있는 데이터 0x11223344를 주소 0x0128에 써야 합니다(이 주소는 태그 및 캐시의 값을 기반으로 계산됩니다). 해당 라인) ). 이 과정은 아래 그림에 나와 있습니다.

writeback 작업이 완료되면 메인 메모리의 0x28 주소에서 시작하는 8바이트를 캐시 라인에 로드하고 더티 비트를 지웁니다. 그런 다음 오프셋에 따라 0x52를 찾아서 CPU에 반환합니다.

인내심을 갖고 읽어주셔서 감사합니다. 이점을 누리시길 바랍니다.

이 기사는 Wowotech에서 복제되었습니다: http://www.wowotech.net/memory_management/458.html

추천 튜토리얼: "Linux Operation and Maintenance"

위 내용은 Linux의 캐시 메모리에 대하여(상세 그림 및 텍스트 설명)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!