[ACA] Memory Hierarchy and Caches (4)

이전 포스팅에서는 Cache Miss가 일어났을 때, 블록을 교체해주는 Eviction Policy에 대해서 알아보았다. 이는 CPU에서 메인 메모리에 데이터를 요청하였을 때 캐시를 잘 활용해보자. 그리고 데이터를 효율적으로 읽어와보자는 관점에서의 이야기였다. 그러면 반대로 CPU에서 연산한 것을 캐시에 써주고, 메모리에 써줄 때는 어떻게 해야할까? CPU에서 연산이 끝난다면 변경된 값을 캐시에 돌려줘야 할 것이고, 캐시에 있는 데이터도 변경된 값을 언젠가는 메인 메모리에 돌려줘야 할 것이다. 이번 포스팅에서는 CPU에서 연산한 값을 언제, 어떻게 메인 메모리에 쓸 것이냐는 관점의 'Write Policy'를 다룰 것이다.

 

우선, 언제 다음 계층에 변경된 데이터를 써줄 것이냐부터 알아보자. 이에 관한 정책으로는 'Write-through', 'Write-back' 두가지가 있다. 이는 Write Hit가 발생해야 시행할 수 있는 정책이기 때문에 'Write Hit Policy'라고도 불린다.

 

Write-through

 

CPU에서 데이터를 쓸 때 캐시와 메인 메모리를 동기적으로 바꿔주는 정책이다. 구현하기 간단하다는 장점이 있고, 모든 계층을 한번에 업데이트 해주기 때문에 메모리간의 consistency를 챙길 수 있다. 하지만, 큰 대역폭이 필요하고 에너지 소모가 크다는 단점이 있다. 최근에 설계되는 프로세서들은 채택하지 않는 정책이다.

 

Write-back

 

CPU에서 데이터를 쓸 때, 블록이 교체되기 전까지 캐시에만 쓰기가 수행되는 정책이다. 만약에 캐시에서 교체 정책에 의해 블록이 교체되면 해당 블록을 메인 메모리에 저장한다. 교체를 하기 이전에 같은 블록에 여러번 쓰기를 할 수 있어서 캐시 레벨간에 대역폭을 절약할 수 있고 이에 때라 에너지도 절약할 수 있다는 장점이 있다. 하지만, 어떤 블록이 변경되었는지 표시하는 태그 스토리지가 더 필요하기 때문에 이 부분이 오버헤드가 될 수 있고, 구현이 어려워 하드웨어 구조가 복잡해지는 단점이 있다. 최근에 설계되는 프로세서들은 이 정책을 채택한다고 한다.

 

위의 정책들은 Write Hit가 발생했을 때, 수행하는 정책들이다.

 

이번에는 쓰기를 할 때, 캐시 블록을 쓰기에 할당할 것이냐에 관한 정책을 알아보겠다. Write Miss가 발생했을 때 옵션으로 생각할 수 있다. 이에 관한 정책으로는 'Write-allocate', 'No-write-allocate' 두가지가 있다.

 

*Write Miss는 쓰려는 주소가 캐시에 없어서 Miss가 나는 경우를 말한다.

 

Write-allocate

이는 Write Miss가 발생했을 때, 캐시에 쓰기를 할 블록을 할당하는 정책이다. 이 정책 이후에는 Write Hit가 일어날 것이기 때문에 위에 둘 정책을 고려한다. 이 정책은 Write Miss가 Read Miss와 같은 방식으로 핸들링되게 때문에 처리하기 간단하다는 장점이 있다. 하지만 전체 캐시 블록을 전송해야 한다는 단점이 있다. 그리고 할당하는 것 자체가 문제가 될 수도 있다. 예를 들어서, 계산한 값을 캐시 메모리에 저장해도 다시 사용하지 않을 것이라면 굳이 캐시 공간을 할당해줄 필요가 없기 때문이다. 이런건 캐시에서 Capacity, Conflict Miss를 일으킬 수도 있는데, 캐시의 성능을 떨어뜨리는 주요 원인이다. 이에 대해서는 다음 포스팅에서 자세히 다루도록 하겠다.

 

No-write-allocate

이는 Write Miss가 발생했을 때, 캐시에 쓰기를 할 블록을 할당하지 않고 메인 메모리에 쓰기를 하는 정책이다. 이는 쓰기의 locality가 낮은 경우에 캐시를 보존해주기 때문에 잠재적으로 cache hit rate을 높일 수 있다는 장점이 있다.