하스웰 haswell-ep 의 qpi snoop configration
Haswell-EP (E5-26xx v3) 를 탑재한 모델 (정확히는 10-Core 이상 부터 적용)에서 추가 된 BIOS 옵션
설정 요약
1. SQL Server, Hyper-V 등의 NUMA Aware Application 에서는 QPI Snoop 을 Cluster On Die로 설정
기존 NUMA 아키텍쳐에서 2 Socket 기준 VM 1개의 최대 메모리 사용량이 1/2 이었다면, COD에서는 1/4로 가용량이 줄어듬
2. Hyper-V 에서의 1개의 최대 VM 메모리가 전체 메모리의 1/4을 초과 하는 경우에는 기본 설정 (Home Snoop)을 유지
(ex> vNUMA 를 지원하지 않는 Legacy Linux VM 등등)
3. NUMA 를 인식하지 않는 Application에서는 (non-aware) 에서는 Early Snoop 을 설정
아키텍쳐 요약
1. 샌디 브릿지 EP 부터 L3 캐시 정책이 링버스로 변경 (코어의 증가로 인한 경로 축소)
2. CPU 코어가 늘어나면서 L3 캐시 접근 정책도 다양화 됨 (경로에 따라 CPU CORE/L3 캐시의 레이턴시가 불균일 해짐)
3. 불균일한 레이턴시를 줄이기 위해 1 Socket 의 CPU 1개를 NUMA 개념으로 2개의 도메인으로 나누어 사용
벤더 (HP)에서는 아래와 같이 요약 하고 있음
|
This option allows for the configurations of different snoop modes that impact the QPI interconnect. Changing this option may improve performance in certain workloads. Home Snoop provides high memory bandwidth in an average NUMA environment (default setting). Cluster on Die may provide increased memory bandwidth in highly optimized NUMA workloads. Early Snoop may decrease memory latency but may also result in lower overall bandwidth as compared to other modes. 1st) Early Snoop (memory latancy-sensitive workloads) |
|
네할렘 마이크로아키텍처가 샌디브릿지로 대체되며 바뀐 가장 큰 구조적 변화는 바로 링 버스 구조를 도입한 것입니다. 멀티코어 다이 구성시 네할렘까지는 각각의 코어와 L3캐시를 각각 독립된 채널을 통해 일대일로 연결해주어야 했고, 이는 UCA (Uniform Cache Access; UMA의 캐시 수준에의 적용) 구현을 위해 당연한 것이었습니다. 그러나 많아 봐야 4코어까지 탑재하는 데스크탑 영역이나, 네할렘-EX의 최대 코어 구성이었던 8코어까지만 하더라도 그로 인한 오버헤드가 심각한 수준이 아니었지만 코어 갯수가 10개를 넘은 웨스트미어-EX부터는 설계의 복잡성이 커지기 시작했습니다. 이래서는 미래에 코어 갯수를 늘릴 때마다 기하급수적으로 늘어나는 채널의 수를 감당할 수 없겠다고 판단한 인텔은 샌디브릿지 마이크로아키텍처부터 링 버스를 도입합니다.
아이비브릿지 마이크로아키텍처에서 하스웰로 이행하며 우선 각급 다이의 코어 갯수가 일제히 늘었습니다. 그러나 달라진 것은 그뿐만이 아닙니다. 언코어 레벨에서 오히려 더 거대한 변화가 가해졌는데, 바로 링 버스가 '분리된' 두 개로 늘었으며, 각 링 버스 사이에 인터커넥트 스위치가 배치되었고, 물리적으로 분리된 링 버스마다 하나씩의 홈 에이전트와 메모리컨트롤러가 배치되었다는 점입니다. 어떤 의미에서는 '아주 타이트하게 결합된' MCM처럼 보일 정도로까지 내부 구조가 변화한 것입니다. 샌디브릿지에서 링 버스 구조를 도입하며 개별 코어가 각기 개별 L3캐시 슬라이스에 접근하는 레이턴시가 다양해질 수 있다는 점은 대표적인 위험 요소였단 이야기를 앞서 했었습니다. 아이비브릿지에서 코어 갯수가 늘어나며 이 부분의 모순이 더욱 커졌지만 그때까지만 하더라도 이로 인한 성능 손실이 눈에 띄는 정도는 아니었던 것 같습니다. 그러나 링 버스 자체가 한 다이 내에서 두 부분으로 분할되고, 각각을 접속시키기 위해 별도의 '스위치'를 거치게 되며 링의 양쪽(편의상 링 도메인이라 합니다)을 오가는 데 소요되는 레이턴시가 급격히 늘게 됩니다. … 메모리컨트롤러가 꺼지는 문제는 인텔이 의도한 부분 같지는 않지만(그렇기에 더 큰 문제일 수 있지만), 사실 그 밖의 '두개의 링 도메인' 구조로부터 파생되는 문제에 관해서는 다행히 인텔이 그에 대처하는 옵션을 제공하고 있습니다. 하스웰-EP/EX부터 새로 도입된 제3의 캐시 일관성 관리 정책인 클러스터 온 다이 (Cluster on Die, COD) 모드가 그것입니다. 단, 이 모드는 두 개 이상의 홈 에이전트를 갖는 10코어 이상 모델 (12코어 다이 이상을 사용한 것) 에 한해 적용 가능합니다. 러프하게 보아 링 도메인을 기준으로, 물리적으로 한개의 다이를 논리적으로 두개의 소켓 (NUMA 도메인) 처럼 인식하는 것입니다. 사실 링 버스 구조 자체가 UCA로부터 멀어진 길이란 점은 위에서 언급했었습니다. 링 도메인이 두개로 분리되면서 하나의 하스웰-EP/EX 다이는 노골적으로 NUCA의 색채를 드러내고 있습니다. 심지어 양쪽 링 도메인이 별개의 메모리컨트롤러를 가지게 되면서, 한 소켓 기준으로 하나의 UMA 쿼드채널이라기보다는 두개의 NUMA 듀얼채널에 가까운 모양이 되었고 실제 작동에서도 비슷한 특성을 보였습니다. COD는 여기서 파생되는 문제점을 해결하기보다, 거꾸로 온전한 NUMA 도메인으로 분리하여 거기서 얻을 수 있는 장점을 키우는 쪽으로 노선을 바꿨습니다. 실제로 COD 모드 하에서 대부분의 멀티코어 최적화 어플리케이션 성능은 눈에 띄게 향상됩니다. 앞서 설명했듯 COD 모드는 캐시 일관성 관리정책의 한 가지입니다. 하스웰-EP/EX 다이 내에서 하나의 코어는 이론적으로 45MB의 L3캐시 모두에 접근할 수 있으나, 만약 필요로 하는 데이터가 다른 링 도메인에 속한 L3캐시에 있다면 이를 액세스하기 위해 큰 레이턴시를 감수해야 합니다. 이런 사례가 빈번하게 일어난다면 전체적인 성능 저하를 피할 수 없습니다. 러프하게 보아 캐시 용량보다 속도가 중요시되는 상황이라면 성능이 떨어집니다. 반면 링 도메인을 기준으로 사실상 별개의 CPU로 간주한다면 코어는 자신과 같은 링 도메인에 속한 L3캐시에만 접근하게 됩니다. 총 용량이 절반이 되므로 캐시 미스는 두배 증가하겠지만 레이턴시 역시 대폭 줄어듭니다. 이것이 COD의 본질입니다. COD의 단점은 COD가 없을 때의 단점을 뒤집어 놓은 것과 같습니다 : 캐시 속도보다 용량이 중요시되는 상황에서 성능이 떨어집니다. 또한 멀티코어에 최적화된 어플리케이션이라도 NUMA 자체에 최적화되지 않았다면 마찬가지로 성능이 떨어집니다. 출처 : http://iyd.kr/738 |
세 번 정독하고 그나마 이해... /전공자에 대한 /존경