MESI 프로토콜
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
MESI 프로토콜은 다중 프로세서 시스템에서 캐시 일관성을 유지하기 위한 널리 사용되는 프로토콜이다. 각 캐시 라인의 상태를 Modified(수정됨), Exclusive(배타적), Shared(공유됨), Invalid(무효)의 네 가지 상태로 정의하며, 프로세서의 읽기/쓰기 요청과 버스 측 요청에 따라 상태가 전환된다. MESI 프로토콜은 MSI 프로토콜에 Exclusive 상태를 추가하여, 데이터 공유가 적은 환경에서 성능을 향상시키지만, 여러 캐시가 동일한 블록에 대해 빈번하게 읽고 쓰는 경우, MOESI 프로토콜과 같은 다른 프로토콜이 더 효율적일 수 있다.
더 읽어볼만한 페이지
- 캐시 일관성 - MSI 프로토콜
MSI 프로토콜은 캐시 일관성을 위해 캐시 라인을 무효, 공유, 수정됨의 세 가지 상태로 관리하며, 프로세서 요청과 버스 요청에 따라 상태가 변경된다.
| MESI 프로토콜 | |
|---|---|
| 기본 정보 | |
| 유형 | 캐시 일관성 프로토콜 |
| 고안 | 컴퓨터 프로세서 |
| 상태 | 수정됨 (Modified) 배타적 (Exclusive) 공유됨 (Shared) 무효화됨 (Invalid) |
2. MESI 프로토콜의 상태
약어 MESI의 각 문자는 캐시 라인이 표시될 수 있는 네 가지 배타적 상태를 나타낸다(두 개의 비트를 사용하여 인코딩됨). 각 캐시 라인은 다음 4가지 상태 중 하나에 있다. 상태는 캐시 라인의 태그에 포함된다(2비트로 표시).
- Modified (수정됨, M): 해당 캐시 라인은 현재 캐시에만 존재하며, 메인 메모리의 값에서 수정되어(M 상태) ''더티'' 상태이다. 캐시는 다른 읽기를 허용하기 전에, 미래의 특정 시점에 데이터를 메인 메모리에 다시 기록해야 하며(더 이상 유효하지 않은) 메인 메모리 상태. 쓰기 백은 라인을 공유 상태(S)로 변경한다.
- Exclusive (배타적, E): 배타적(Exclusive, E) 상태의 캐시 라인은 현재 캐시에만 존재하며 "클린" 상태, 즉 메인 메모리와 일치한다. 읽기 요청에 응답하여 언제든지 공유 상태(S)로 변경될 수 있다. 또는 쓰기를 할 때 수정된 상태(M)로 변경될 수 있다.
- Shared (공유됨, S): Shared (공유됨, S) 상태의 캐시 라인은 이 캐시 라인이 머신의 다른 캐시에 저장될 수 있으며 ''클린'' 상태, 즉 메인 메모리와 일치함을 나타낸다. 이 라인은 언제든지 폐기될 수 있다(무효 상태로 변경).
- Invalid (무효, I): MESI에서 무효(Invalid, I) 상태는 캐시 라인이 사용되지 않거나 유효하지 않음을 나타낸다. 블록이 M(수정됨) 또는 E(배타적)로 표시되면, 다른 캐시의 블록 복사본은 I(무효)로 표시된다.
임의의 두 캐시가 있을 때, 각 캐시에 해당하는 캐시 라인이 가질 수 있는 상태의 조합은 다음과 같다.
| M | E | S | I | |
|---|---|---|---|---|
| M | ||||
| E | ||||
| S | ||||
| I |
2. 1. Modified (수정됨, M)
해당 캐시 라인은 현재 캐시에만 존재하며, 메인 메모리의 값에서 수정되어(M 상태) ''더티'' 상태이다. 캐시는 다른 읽기를 허용하기 전에, 미래의 특정 시점에 데이터를 메인 메모리에 다시 기록해야 하며(더 이상 유효하지 않은) 메인 메모리 상태. 쓰기 백은 라인을 공유 상태(S)로 변경한다.2. 2. Exclusive (배타적, E)
배타적(Exclusive, E) 상태의 캐시 라인은 현재 캐시에만 존재하며 "클린" 상태, 즉 메인 메모리와 일치한다. 읽기 요청에 응답하여 언제든지 공유 상태(S)로 변경될 수 있다. 또는 쓰기를 할 때 수정된 상태(M)로 변경될 수 있다.2. 3. Shared (공유됨, S)
Shared (공유됨, S) 상태의 캐시 라인은 이 캐시 라인이 머신의 다른 캐시에 저장될 수 있으며 ''클린'' 상태, 즉 메인 메모리와 일치함을 나타낸다. 이 라인은 언제든지 폐기될 수 있다(무효 상태로 변경).2. 4. Invalid (무효, I)
MESI에서 무효(Invalid, I) 상태는 캐시 라인이 사용되지 않거나 유효하지 않음을 나타낸다. 블록이 M(수정됨) 또는 E(배타적)로 표시되면, 다른 캐시의 블록 복사본은 I(무효)로 표시된다.3. MESI 프로토콜의 동작
MESI 프로토콜에서 각 캐시 블록은 자체적인 4가지 상태 유한 상태 기계를 가진다.[3] 상태 전환은 프로세서의 읽기/쓰기 요청과 버스 측 요청(BusRd, BusRdX, BusUpgr, Flush, FlushOpt)에 의해 발생한다.
프로세서 요청은 다음과 같다.[3]
- PrRd: 프로세서가 캐시 블록 읽기를 요청한다.
- PrWr: 프로세서가 캐시 블록 쓰기를 요청한다.
버스 측 요청은 다음과 같다.[3]
- BusRd: 다른 프로세서가 요청한 캐시 블록에 대한 읽기 요청이 있음을 나타내는 스누핑된 요청이다.
- BusRdX: 다른 프로세서가 요청한 캐시 블록에 대한 쓰기 요청이 있음을 나타내는 스누핑된 요청으로, 해당 블록이 아직 없는 경우이다.
- BusUpgr: 이미 자신의 캐시에 캐시 블록이 있는 다른 프로세서가 요청한 캐시 블록에 대한 쓰기 요청이 있음을 나타내는 스누핑된 요청이다.
- Flush: 다른 프로세서가 전체 캐시 블록을 주 메모리에 다시 쓰도록 지시하는 스누핑된 요청이다.
- FlushOpt: 다른 프로세서에 제공하기 위해 전체 캐시 블록이 버스에 게시되었음을 나타내는 스누핑된 요청이다(캐시 간 전송).
스누퍼[4]는 버스의 모든 트랜잭션을 모니터링하여 이러한 요청들을 감지한다.
캐시 라인이 수정(M) 또는 독점(E) 상태에 있는 경우에만 자유롭게 쓰기를 수행할 수 있다. 공유(S) 상태인 경우에는 다른 모든 캐시된 복사본을 먼저 무효화해야 하며, 이는 ''소유권 요청(RFO)''이라는 브로드캐스트 연산을 통해 수행된다.
수정(M) 상태의 캐시는 해당 주 메모리 위치의 모든 읽기 시도를 스누핑(가로채기)하고 보관한 데이터를 삽입해야 한다. 공유(S) 상태의 캐시는 다른 캐시에서 보낸 무효화 또는 소유권 요청 브로드캐스트를 수신 대기하고, 일치하는 경우 해당 라인을 무효(I) 상태로 변경해야 한다.
독점(E) 상태는 다른 캐시가 해당 라인을 공유하지 않을 때, 버스 트랜잭션 없이 캐시 라인을 수정할 수 있게 해주는 최적화이다.
| 초기 상태 | 연산 | 응답 |
|---|---|---|
| 무효(I) | PrRd | |
| PrWr | ||
| 독점(E) | PrRd | |
| PrWr | ||
| 공유(S) | PrRd | |
| PrWr | ||
| 수정됨(M) | PrRd | |
| PrWr |
| 초기 상태 | 연산 | 응답 |
|---|---|---|
| 무효(I) | BusRd | |
| BusRdX/BusUpgr | ||
| 독점(E) | BusRd | |
| BusRdX | ||
| 공유(S) | BusRd | |
| BusRdX/BusUpgr | ||
| 수정됨(M) | BusRd | |
| BusRdX |
MESI 프로토콜 연산의 예시는 다음과 같다.
| '로컬' '요청' | big>P1' | big>P2' | 'P3' | 생성됨 | 데이터 공급자 | |
|---|---|---|---|---|---|---|
| 0 | 초기 | - | - | - | - | - |
| 1 | R1 | E | - | - | BusRd | Mem |
| 2 | W1 | M | - | - | - | - |
| 3 | R3 | S | - | S | BusRd | P1의 캐시 |
| 4 | W3 | I | - | M | BusUpgr | - |
| 5 | R1 | S | - | S | BusRd | P3의 캐시 |
| 6 | R3 | S | - | S | - | - |
| 7 | R2 | S | S | S | BusRd | P1/P3의 캐시 |
3. 1. 프로세서 요청
MESI 프로토콜에서 프로세서 요청은 프로세서가 캐시 블록에 대해 수행하는 연산이다.프로세서가 읽기 또는 쓰기 요청을 할 때, 해당 캐시 블록의 상태와 다른 프로세서의 캐시 상태에 따라 버스 트랜잭션이 발생할 수 있다. 예를 들어, 프로세서가 캐시 블록에 쓰기 요청(PrWr)을 할 때, 해당 블록이 공유(S) 상태라면 다른 캐시의 복사본을 무효화하기 위해 BusUpgr 신호를 발생시킨다.[3][4]
만약 해당 블록이 무효(I) 상태라면, 다른 프로세서의 캐시에 해당 블록의 복사본이 있는지 확인하고, 있다면 그 값을 가져오거나 주 메모리에서 가져오기 위해 BusRdX 신호를 발생시킨다.
캐시 라인이 수정(M) 또는 독점(E) 상태에 있는 경우에만 자유롭게 쓰기를 수행할 수 있다.[4] 공유 상태인 경우에는 다른 모든 캐시된 복사본을 먼저 무효화해야 하며, 이는 소유권 요청(RFO)이라고 하는 브로드캐스트 연산으로 수행된다.
3. 2. 버스 측 요청
MESI 프로토콜에서 버스 측 요청은 캐시 블록이나 업데이트된 데이터를 캐시에 가지고 있지 않은 다른 프로세서에서 발생한다. 이러한 버스 요청은 모든 버스 트랜잭션을 모니터링하는 스누퍼[4]의 도움을 받아 감시된다.
다음은 버스 측 요청의 다양한 유형이다.
- BusRd: 다른 프로세서가 요청한 캐시 블록에 대한 '''읽기''' 요청이 있음을 나타내는 스누핑된 요청이다.[3]
- BusRdX: 다른 프로세서가 요청한 캐시 블록에 대한 '''쓰기''' 요청이 있음을 나타내는 스누핑된 요청으로, '''해당 블록이 아직 없는 경우'''이다.[3]
- BusUpgr: 이미 '''자신의 캐시에 캐시 블록이 있는''' 다른 프로세서가 요청한 캐시 블록에 대한 쓰기 요청이 있음을 나타내는 스누핑된 요청이다.[3]
- Flush: 다른 프로세서가 전체 캐시 블록을 주 메모리에 다시 쓰도록 지시하는 스누핑된 요청이다.[3]
- FlushOpt: 다른 프로세서에 제공하기 위해 전체 캐시 블록이 버스에 게시되었음을 나타내는 스누핑된 요청이다(캐시 간 전송).[3] 이러한 캐시 간 전송은 주 메모리에서 블록을 가져오는 대기 시간이 캐시 간 전송보다 더 긴 경우, 읽기 미스 대기 시간을 줄일 수 있다.
스누핑 시스템에서 버스의 모든 캐시는 해당 버스의 모든 트랜잭션을 모니터링한다. 모든 캐시는 저장된 모든 물리적 메모리 블록의 공유 상태 복사본을 가지고 있다. 블록의 상태는 사용된 프로토콜의 상태 다이어그램에 따라 변경된다. 버스에는 양쪽에 스누퍼가 있다. 프로세서/캐시 측 스누퍼와 메모리 측의 스누핑 기능은 메모리 컨트롤러가 수행한다.
각 캐시 블록에는 자체적인 4가지 상태 유한 상태 기계가 있다(그림 1.1 참조).
캐시 라인이 수정 또는 독점 상태에 있는 경우에만 자유롭게 쓰기를 수행할 수 있다. 공유 상태인 경우 다른 모든 캐시된 복사본을 먼저 무효화해야 한다. 이는 일반적으로 ''소유권 요청(RFO)''이라고 하는 브로드캐스트 연산으로 수행된다.
수정 상태로 라인을 보관하는 캐시는 해당 주 메모리 위치의 모든 읽기 시도(시스템의 다른 모든 캐시에서)를 ''스누핑''(가로채기)하고 보관한 데이터를 삽입해야 한다. 이는 읽기가 ''백오프''(예: 나중에 재시도)하도록 강제한 다음 데이터를 주 메모리에 쓰고 캐시 라인을 공유 상태로 변경하여 수행할 수 있다.
공유 상태로 라인을 보관하는 캐시는 다른 캐시에서 보낸 무효화 또는 소유권 요청 브로드캐스트를 수신 대기하고 일치하는 경우 라인을 폐기(무효 상태로 이동)해야 한다.
수정 및 독점 상태는 항상 정확하지만, 공유 상태는 부정확할 수 있다. 다른 캐시가 공유 라인을 폐기하면 이 캐시가 해당 캐시 라인의 유일한 소유자가 될 수 있지만 독점 상태로 승격되지 않는다. 다른 캐시는 캐시 라인을 폐기할 때 알림을 브로드캐스트하지 않으며, 이 캐시는 공유 복사본 수를 유지 관리하지 않고 이러한 알림을 사용할 수 없다.
3. 3. 스누핑 연산
스누핑 시스템에서 모든 캐시는 버스의 모든 트랜잭션을 모니터링하여 캐시 일관성을 유지한다.[4] 각 캐시는 저장된 모든 물리적 메모리 블록의 공유 상태 복사본을 가진다. 블록의 상태는 사용된 프로토콜(MESI 상태 다이어그램은 위 그림 1.1 참조)의 상태 다이어그램에 따라 변경된다.
버스에는 양쪽에 스누퍼가 있다.
# 프로세서/캐시 측 스누퍼.
# 메모리 측의 스누핑 기능은 메모리 컨트롤러가 수행한다.
각 캐시 블록에는 자체적인 4가지 상태 유한 상태 기계가 있다(그림 1.1 참조).
캐시 라인이 수정 또는 독점 상태에 있는 경우에만 자유롭게 쓰기를 수행할 수 있다. 공유 상태인 경우 다른 모든 캐시된 복사본을 먼저 무효화해야 한다. 이는 일반적으로 ''소유권 요청(RFO)''이라고 하는 브로드캐스트 연산으로 수행된다.
수정 상태로 라인을 보관하는 캐시는 해당 주 메모리 위치의 모든 읽기 시도(시스템의 다른 모든 캐시에서)를 ''스누핑''(가로채기)하고 보관한 데이터를 삽입해야 한다. 이는 읽기가 ''백오프''(예: 나중에 재시도)하도록 강제한 다음 데이터를 주 메모리에 쓰고 캐시 라인을 공유 상태로 변경하여 수행할 수 있다. 또한 수정된 캐시에서 읽기를 수행하는 캐시로 데이터를 전송하여 수행할 수도 있다. 스누핑은 읽기 미스에만 필요하다(프로토콜은 다른 캐시가 읽기 적중을 수행할 수 있는 경우 수정된 상태가 존재할 수 없도록 보장한다).
공유 상태로 라인을 보관하는 캐시는 다른 캐시에서 보낸 무효화 또는 소유권 요청 브로드캐스트를 수신 대기하고 일치하는 경우 라인을 폐기(무효 상태로 이동)해야 한다.
수정 및 독점 상태는 항상 정확하다. 즉, 시스템의 실제 캐시 라인 소유권 상황과 일치한다. 공유 상태는 부정확할 수 있다. 다른 캐시가 공유 라인을 폐기하면 이 캐시가 해당 캐시 라인의 유일한 소유자가 될 수 있지만 독점 상태로 승격되지 않는다. 다른 캐시는 캐시 라인을 폐기할 때 알림을 브로드캐스트하지 않으며, 이 캐시는 공유 복사본 수를 유지 관리하지 않고 이러한 알림을 사용할 수 없다.
그런 의미에서 독점 상태는 기회적 최적화이다. CPU가 S 상태의 캐시 라인을 수정하려는 경우, 버스 트랜잭션이 다른 모든 캐시된 복사본을 무효화하는 데 필요하다. 상태 E는 버스 트랜잭션 없이 캐시 라인을 수정할 수 있도록 한다.
'''MESI 프로토콜 연산의 예시'''
예를 들어, 다음과 같은 읽기/쓰기 참조 스트림이 있다. 모든 참조는 동일한 위치에 있으며 숫자는 참조를 발행하는 프로세서를 나타낸다.
스트림은 다음과 같다: R1, W1, R3, W3, R1, R3, R2.
처음에는 모든 캐시가 비어 있다고 가정한다.
- 1단계: 캐시가 처음에 비어 있으므로 주 메모리가 P1에 블록을 제공하고 독점 상태가 된다.
- 2단계: 블록이 이미 캐시에 있고 독점 상태이므로 버스 명령 없이 직접 수정한다. 블록은 이제 수정된 상태이다.
- 3단계: 이 단계에서 BusRd가 버스에 게시되고 P1의 스누퍼가 이를 감지한다. 그런 다음 데이터를 플러시하고 상태를 공유로 변경한다. P3의 블록도 다른 캐시에서 데이터를 수신했으므로 상태가 공유로 변경된다. 데이터는 또한 주 메모리에 다시 기록된다.
- 4단계: 여기서 BusUpgr가 버스에 게시되고 P1의 스누퍼가 이를 감지하여 다른 캐시에서 수정할 것이므로 블록을 무효화한다. 그런 다음 P3는 블록 상태를 수정으로 변경한다.
- 5단계: 현재 상태가 무효이므로 버스에 BusRd를 게시한다. P3의 스누퍼가 이를 감지하여 데이터를 플러시한다. P1과 P3의 두 블록 모두의 상태가 이제 공유가 된다. 이는 이전에 수정된 데이터로 주 메모리가 업데이트될 때이다.
- 6단계: 캐시에 적중이 있고 공유 상태이므로 여기서는 버스 요청이 이루어지지 않는다.
- 7단계: P2에서 캐시 미스가 발생하고 BusRd가 게시된다. P1 및 P3의 스누퍼가 이를 감지하고 모두 플러시를 시도한다. 먼저 버스에 액세스하는 사람이 해당 작업을 수행한다.
3. 4. 상태 전환
MESI 프로토콜에서 각 캐시 블록은 자체적인 4가지 상태 유한 상태 기계(FSM)를 갖는다.[3] 상태 전환은 프로세서의 읽기/쓰기 요청 및 버스 측 요청에 의해 발생한다.프로세서 요청은 다음과 같다.[3]
- PrRd: 프로세서가 캐시 블록 읽기를 요청한다.
- PrWr: 프로세서가 캐시 블록 쓰기를 요청한다.
버스 측 요청은 다음과 같다.[3]
- BusRd: 다른 프로세서가 요청한 캐시 블록에 대한 읽기 요청이 있음을 나타내는 스누핑된 요청이다.
- BusRdX: 다른 프로세서가 요청한 캐시 블록에 대한 쓰기 요청이 있음을 나타내는 스누핑된 요청으로, 해당 블록이 아직 없는 경우이다.
- BusUpgr: 이미 자신의 캐시에 캐시 블록이 있는 다른 프로세서가 요청한 캐시 블록에 대한 쓰기 요청이 있음을 나타내는 스누핑된 요청이다.
- Flush: 다른 프로세서가 전체 캐시 블록을 주 메모리에 다시 쓰도록 지시하는 스누핑된 요청이다.
- FlushOpt: 다른 프로세서에 제공하기 위해 전체 캐시 블록이 버스에 게시되었음을 나타내는 스누핑된 요청이다(캐시 간 전송).
스누퍼[4]는 버스의 모든 트랜잭션을 모니터링하여 이러한 요청들을 감지한다.
캐시 라인이 수정(Modified) 또는 독점(Exclusive) 상태에 있는 경우에만 자유롭게 쓰기를 수행할 수 있다. 공유(Shared) 상태인 경우에는 다른 모든 캐시된 복사본을 먼저 무효화해야 하며, 이는 ''소유권 요청(RFO)''이라는 브로드캐스트 연산을 통해 수행된다.
수정(Modified) 상태의 캐시는 해당 주 메모리 위치의 모든 읽기 시도를 스누핑(가로채기)하고 보관한 데이터를 삽입해야 한다. 공유(Shared) 상태의 캐시는 다른 캐시에서 보낸 무효화 또는 소유권 요청 브로드캐스트를 수신 대기하고, 일치하는 경우 해당 라인을 무효(Invalid) 상태로 변경해야 한다.
독점(Exclusive) 상태는 다른 캐시가 해당 라인을 공유하지 않을 때, 버스 트랜잭션 없이 캐시 라인을 수정할 수 있게 해주는 최적화이다.
다음 표는 다양한 프로세서 연산 및 버스 연산에 대한 상태 전환 및 응답을 나타낸다.
| 초기 상태 | 연산 | 응답 |
|---|---|---|
| 무효(I) | PrRd | |
| PrWr | ||
| 독점(E) | PrRd | |
| PrWr | ||
| 공유(S) | PrRd | |
| PrWr | ||
| 수정됨(M) | PrRd | |
| PrWr |
| 초기 상태 | 연산 | 응답 |
|---|---|---|
| 무효(I) | BusRd | |
| BusRdX/BusUpgr | ||
| 독점(E) | BusRd | |
| BusRdX | ||
| 공유(S) | BusRd | |
| BusRdX/BusUpgr | ||
| 수정됨(M) | BusRd | |
| BusRdX |
MESI 프로토콜 연산의 예시는 다음과 같다.
| '로컬' '요청' | big>P1' | big>P2' | 'P3' | 생성됨 | 데이터 공급자 | |
|---|---|---|---|---|---|---|
| 0 | 초기 | - | - | - | - | - |
| 1 | R1 | E | - | - | BusRd | Mem |
| 2 | W1 | M | - | - | - | - |
| 3 | R3 | S | - | S | BusRd | ''P1s 캐시''' |
| 4 | W3 | I | - | M | BusUpgr | - |
| 5 | R1 | S | - | S | BusRd | P3의 캐시 |
| 6 | R3 | S | - | S | - | - |
| 7 | R2 | S | S | S | BusRd | P1/P3의 캐시 |
4. Read For Ownership (RFO)
Read For Ownership (RFO)는 캐시 일관성 프로토콜에서 읽기와 무효화 브로드캐스트를 결합한 연산이다. 이 연산은 MESI 프로토콜의 공유(S) 또는 무효(I) 상태에 있는 캐시 라인에 쓰기를 시도하는 프로세서에 의해 발행된다. 이 연산은 다른 모든 캐시가 해당 라인의 상태를 I로 설정하게 한다. 소유권 획득을 위한 읽기 트랜잭션은 해당 메모리 주소에 쓰기를 하려는 의도를 가진 읽기 연산이다. 따라서 이 연산은 배타적이다. 이 연산은 데이터를 캐시로 가져오고 이 메모리 라인을 가지고 있는 다른 모든 프로세서 캐시를 무효화한다. 위 표에서 이것은 "BusRdX"로 명명된다.
5. 메모리 장벽 (Memory Barriers)
MESI의 단순 구현은 성능 문제를 야기하는데, 이를 완화하기 위해 저장 버퍼와 무효화 큐가 사용된다.[5] 저장 버퍼는 유효하지 않은 캐시 라인에 쓰기를 시도할 때 발생하는 지연 시간을 줄여준다. CPU는 읽기-무효화 메시지를 보내고, 캐시 라인이 도착하면 실행될 쓰기를 저장 버퍼에 넣어둔다. CPU는 캐시 라인을 읽어야 할 때 자신의 저장 버퍼를 확인하여 이전 쓰기가 있는지 확인한다. 하지만 다른 CPU는 캐시에 플러시될 때까지 해당 쓰기를 볼 수 없다.[5]
무효화 큐는 들어오는 무효화 요청을 즉시 처리하지 않고 큐에 넣어 지연 처리를 가능하게 한다. 이로 인해 CPU는 캐시 라인이 실제로 무효화되었는지 즉시 알 수 없다. 이러한 문제를 해결하기 위해 메모리 장벽이 필요하다.[5]
메모리 장벽은 저장 버퍼와 무효화 큐를 플러시하여 메모리 일관성을 보장한다. ''저장 장벽(Store Barrier)''은 저장 버퍼를 플러시하여 모든 쓰기가 해당 CPU의 캐시에 적용되도록 한다. ''읽기 장벽(Read Barrier)''은 무효화 큐를 플러시하여 다른 CPU의 모든 쓰기가 해당 CPU에 보이도록 한다. 메모리 관리 장치도 저장 버퍼를 스캔하지 않기 때문에 유사한 문제가 발생할 수 있으며, 이는 단일 스레드 프로세서에서도 나타난다.[6]
6. MSI 프로토콜과의 비교
MESI 프로토콜과 MSI의 가장 큰 차이점은 MESI 프로토콜에는 "Exclusive(배타적)" 상태가 추가되었다는 것이다. 이 상태는 다른 프로세서가 '''아무것도 가지고 있지 않은''' 블록을 프로세서가 읽고 써야 할 경우, MSI에서 발생하는 두 번의 버스 트랜잭션을 줄이기 위해 추가되었다. MSI에서는 BusRd 요청으로 블록을 읽고, BusUpgr 요청으로 블록에 쓰기 전에 두 번의 버스 트랜잭션이 발생한다. 이 때, 다른 캐시에 동일한 블록이 없어도 BusRd 요청은 발행되지만, MESI 프로토콜은 Exclusive 상태를 통해 이러한 불필요한 버스 요청을 줄인다.
이러한 차이로 인해 순차적인 응용 프로그램이나 데이터 공유가 최소화된 병렬 응용 프로그램에서 MESI 프로토콜이 더 효율적이다. 순차적인 응용 프로그램에서는 하나의 프로세서만 데이터에 접근하므로 모든 접근이 전용 상태가 되어 MSI 프로토콜보다 성능이 향상된다. 데이터 공유가 적은 병렬 응용 프로그램에서도 MESI 프로토콜이 더 빠르다.
Exclusive 상태는 2비트로 표현 가능하므로 추가 비용이 발생하지 않는다.
7. MESI 프로토콜의 장단점
MESI 프로토콜은 MSI에 "Exclusive(전용)" 상태를 추가하여 성능을 향상시킨 프로토콜이다. 다른 프로세서가 가지고 있지 않은 블록을 읽고 쓸 때, MSI는 두 번의 버스 트랜잭션(BusRd, BusUpgr)을 발생시킨다. 하지만 MESI는 Exclusive 상태를 통해 이러한 불필요한 버스 요청을 줄인다.[7] 이는 순차적인 응용 프로그램이나 데이터 공유가 적은 병렬 응용 프로그램에서 큰 성능 향상을 가져온다.[7] Exclusive 상태 추가는 상태 표현 비트 수를 늘리지 않으므로 추가 비용이 없다.
반면, 여러 캐시가 동일한 블록에 대해 지속적으로 읽기 및 쓰기를 수행하는 경우, MESI 프로토콜은 매번 데이터를 버스로 플러시하여 주 메모리를 깨끗한 상태로 유지한다. 이는 MOESI 프로토콜에서 해결된 문제이다.[7] 또한, 공유 상태(S)에서 여러 스누퍼가 동일한 데이터로 FlushOpt에 응답할 수 있는 중복성은 MESIF의 F 상태에서 해결된다.
8. 기타 캐시 일관성 프로토콜
8. 1. MSI 프로토콜
MSI 프로토콜은 캐시 일관성 프로토콜 중 하나로, MESI 프로토콜과 달리 Exclusive 상태를 가지지 않는다. MESI 프로토콜에서 Exclusive 상태가 되는 상황에서는 Shared 상태가 된다.Invalid 상태의 캐시 라인에 CPU가 읽기를 수행할 때, 다른 캐시에 해당 캐시 라인이 Modified 상태로 존재하지 않음을 확인해야 한다. 이를 위해 버스 스누핑을 통해 읽기 요청 브로드캐스트를 감시하거나, 각 캐시 라인을 최근에 읽은 캐시 정보를 저장하는 방식을 사용한다. Modified 상태의 캐시 라인을 다른 캐시가 소유한 경우, 주 기억 장치에 내용을 기록하고 해당 캐시 라인은 Shared 또는 Invalid 상태로 변경한다. 이후 Shared 상태의 캐시 라인에는 주 기억 장치나 다른 Shared 상태의 캐시에서 데이터를 읽어와 Shared 상태로 전환한다.
쓰기 요청의 경우, 캐시 라인이 Modified 상태면 로컬 캐시에 바로 쓰기를 수행한다. Shared 상태라면, 다른 캐시의 Shared 상태 캐시 라인을 무효화하고 Modified 상태로 전환하여 로컬 캐시에 쓰기를 수행한다. Invalid 상태일 때는 다른 캐시의 Shared 및 Modified 상태 캐시 라인을 무효화해야 한다. Modified 상태의 캐시 라인이 존재하면, 해당 내용을 주 기억 장치에 쓰거나 쓰기를 요청한 캐시로 전송한다. 일반적으로 CPU 쓰기 요청은 워드 단위이지만 캐시 라인은 여러 워드로 구성되므로, Invalid 상태에서 쓰기 요청 시 캐시 라인 전체를 먼저 읽어야 한다.
두 캐시가 있을 때 각 캐시 라인의 상태 조합은 다음과 같다.
| M | S | I | |
|---|---|---|---|
| M | 20px | 20px | |
| S | 20px | ||
| I |
8. 2. MOSI 프로토콜
'''MOSI 프로토콜'''은 MESI 프로토콜의 Exclusive 상태 대신 Owned(소유) 상태를 가지는 캐시 일관성 프로토콜이다. MSI 프로토콜에 Owned 상태를 더한 것으로 볼 수 있으며, 이 프로토콜에서 Exclusive 상태는 Shared 상태에 포함된다.Owned 상태의 캐시 라인은 ''dirty'' 상태이며, 주 기억 장치에 다시 쓰기(write-back)가 필요하다. Modified 상태의 캐시 라인에 해당하는 주소에 다른 CPU가 읽기(read) 요청을 발행했을 때, Owned 상태로 전환된다. Owned 상태의 캐시 라인을 가진 캐시 기구는 해당 주소 범위에 대한 읽기 요청에 대해 주 기억 장치를 대신하여 응답한다. 즉, 해당 캐시 라인은 다른 CPU에서는 Shared 상태가 된다. Owned 상태에서 추가적인 변경을 가할 때에는, 다른 캐시의 Shared 상태인 해당 캐시 라인을 무효화하고 자신은 Modified 상태로 전환하거나, 다른 캐시에 업데이트 내용을 전송하여 Shared 상태를 유지시킨다(아키텍처에 따라 다르다).
임의의 두 개의 캐시가 있을 때, 각각의 대응하는 캐시 라인이 가질 수 있는 상태 조합은 다음과 같다.
| M | O | S | I | |
|---|---|---|---|---|
| M | 20px | 20px | 20px | |
| O | 20px | 20px | ||
| S | 20px | |||
| I |
8. 3. MOESI 프로토콜
MOESI 프로토콜은 MESI 프로토콜에 Owned 상태를 추가한 캐시 일관성 프로토콜이다. AMD64에서 채택되었다.[9]MESI 프로토콜에서는 특정 블록에 대해 여러 캐시에서 지속적인 읽기 및 쓰기 작업이 수행되는 경우, 매번 데이터를 버스로 플러시해야 했다. 하지만 MOESI 프로토콜에서는 ''dirty''한 캐시 라인을 가진 상태에서 다른 캐시로부터 읽기 요청이 있을 때, 주 기억 장치에 다시 기록할 필요 없이 Owned 상태의 캐시 라인이 직접 변경된 데이터를 다른 프로세서에 보낼 수 있다. 이는 캐시 간 통신이 주 기억 장치와의 통신보다 빠른 경우, 예를 들어 멀티 코어 CPU에서 CPU마다 L2 캐시가 있는 경우 등에 유리하다.
임의의 두 캐시가 있을 때, 각 캐시에 해당하는 캐시 라인이 가질 수 있는 상태의 조합은 다음과 같다.
| M | O | E | S | I | |
|---|---|---|---|---|---|
| M | 20px | 20px | 20px | 20px | |
| O | 20px | 20px | 20px | ||
| E | 20px | 20px | 20px | 20px | |
| S | 20px | 20px | |||
| I |
S (공유 상태)의 경우, 여러 스누퍼가 동일한 데이터로 FlushOpt에 응답할 수 있는데, MESIF의 F 상태는 이러한 중복성을 해결한다.[7]
참조
[1]
서적
Proceedings of the 11th annual international symposium on Computer architecture - ISCA '84
2013-03-19
[2]
논문
MESI Cache Coherence Simulator for Teaching Purposes
[3]
서적
Parallel Computer Architecture
Morgan Kaufmann Publishers
[4]
웹사이트
An evaluation of Snoopy Based Cache Coherence protocols
http://hps.ece.utexa[...]
ECE Department, University of Texas at Austin
[5]
서적
The Cache Memory Book
Morgan Kaufmann
[6]
서적
Verified Software: Theories, Tools and Experiments
[7]
웹사이트
Memory System (Memory Coherency and Protocol)
http://www.cs.wustl.[...]
AMD64 Technology
2006-09
[8]
문서
IA-32 Intel Architecture Software Developers Manual
[9]
간행물
AMD64 Architecture Programmer's Manual Vol 2 'System Programming'
http://support.amd.c[...]
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com