🧩 CPU

AMD Unified CCX

개요

AMD Zen 3의 Unified CCX는 한 CCD 안의 최대 8개 코어가 하나의 32MB L3 cache group을 공유하도록 만든 core complex 구조다. Zen 2에서는 CCD 안에 4코어 CCX 두 개가 있고 각 CCX가 16MB L3를 공유했기 때문에, 서로 다른 CCX의 코어가 데이터를 공유하면 같은 CCD 안에서도 추가적인 cache-fabric·coherence 경계를 통과해야 했다. Zen 3는 이 경계를 CCD 내부에서 없애 shared-data locality를 단순화했다.

여기서 Unified CCX는 Zen 3의 8-core unified complex를 설명하기 위한 분석 용어다. AMD의 공개 자료는 세대와 제품에 따라 unified complex, CPU complex, CCD 등의 표현을 사용하므로 모든 AMD CPU의 고정된 부품명으로 확대해서는 안 된다. 또한 unified L3가 다른 CCD, Central IOD 또는 다른 socket까지 같은 latency를 제공한다는 뜻도 아니다. 이 문서는 동일 CCD의 cache locality 개선과 chiplet·NUMA 경계를 분리해 설명한다.

핵심 개념

1. CCX, CCD와 Unified CCX의 범위

용어	의미	Unified CCX와의 관계	주의할 점
Core	명령을 실행하고 private cache를 사용하는 CPU 코어	unified L3 group에 참여	코어 수와 enable 상태는 SKU마다 다름
CCX	코어와 공유 L3를 묶는 논리적 locality 단위	Zen 3에서는 8코어 unified complex를 가리키는 방식으로 설명되는 경우가 많음	AMD 공식 명칭과 세대별 grouping을 확인해야 함
CCD	코어와 L2/L3를 담은 compute die	하나 이상의 compute complex를 담는 물리적 경계	Zen 2와 Zen 3의 내부 cache grouping이 다름
L3 cache group	여러 코어가 공동으로 사용하는 마지막 수준 cache	Zen 3에서는 CCD당 대표적으로 32MB를 8코어가 공유	용량이 같아도 접근 경로·경쟁은 세대별로 다름
Infinity Fabric	core, cache, CCD, IOD와 socket 사이의 transaction fabric	unified complex 밖의 remote 요청과 coherence/data traffic을 운반	단일 bus, 고정 clock 또는 단일 topology가 아님
IOD	memory controller, PCIe와 외부 link를 수용하는 I/O die	다른 CCD와 memory/I/O service의 경계	Zen 3 client와 EPYC의 제품 구성을 같은 모델로 쓰지 않음

Unified가 뜻하는 것은 한 CCD 내부에서 L3의 공유 범위를 넓힌 것이다. 여러 CCD의 L3를 하나의 물리적 cache로 합친 것이 아니며, DRAM latency나 socket 간 NUMA 비용을 제거한 것도 아니다. 따라서 8코어 unified L3와 전체 CPU의 shared L3를 같은 표현으로 사용하지 않는다.

2. Zen 2에서 Zen 3로 바뀐 locality

구분	Zen 2의 대표 구조	Zen 3의 대표 구조
CCD 내부 compute group	4코어 CCX 두 개	최대 8코어 unified complex 하나
공유 L3	CCX당 16MB, CCD 합계 32MB 모델	unified group당 32MB 모델
같은 CCD의 다른 그룹 접근	CCX 간 추가 cache-fabric/coherence 경계	같은 L3 group 안에서 처리하는 경로로 단순화
다른 CCD 접근	CCD 경계와 fabric 경유	CCD 경계와 fabric 경유, 여전히 remote
memory miss	local L3 miss 후 fabric을 통해 memory service	local L3 miss 후 fabric을 통해 memory service
핵심 성능 효과	core placement에 CCX 경계를 반영해야 함	shared working set을 같은 CCD에 유지하기 쉬움

Zen 3의 32MB는 Zen 2의 CCD 합계 32MB와 숫자만 같지만 locality 의미가 다르다. Zen 2에서는 16MB씩 나뉜 두 CCX가 각각 local group이었고, Zen 3에서는 최대 8코어가 하나의 32MB group을 공유한다. 그러므로 총 cache 용량만 비교해서는 unified 구조의 이득을 설명할 수 없다.

3. Unified L3가 개선하는 것과 개선하지 않는 것

개선하는 범위

같은 CCD 안의 코어가 shared read-mostly data를 소비할 때 cache group 경계를 단순화한다.
Zen 2에서 서로 다른 CCX에 배치된 코어 사이의 L3 locality 차이를 줄인다.
스레드 배치가 CCX 경계를 넘는지보다 CCD와 L3 group의 경계를 먼저 보는 분석이 가능하다.
같은 CCD 안의 producer-consumer, barrier와 일부 lock workload에서 remote-group traffic을 줄일 여지가 있다.

그대로 남는 범위

private L1/L2 miss, L3 tag/data lookup과 cache contention 자체는 사라지지 않는다.
다른 CCD의 cache line이나 home에 접근하면 CCD-to-CCD fabric traversal과 coherence 처리가 필요하다.
L3 miss가 DRAM으로 가면 IOD, memory controller queue와 DRAM timing이 지연을 결정한다.
다른 socket 접근은 socket link와 remote NUMA service를 추가한다.

4. Cache coherence와 Unified CCX

Unified CCX는 coherence protocol을 대체하는 기능이 아니다. 각 코어의 private cache와 shared L3는 cache-line state, ownership과 permission을 관리하고, fabric은 lookup 결과에 따라 request, data, invalidate, snoop와 acknowledgement를 운반한다. 실제 directory, probe filter, home 선택과 data-forwarding 정책은 제품별 공개 범위가 제한된다.

read-mostly 데이터는 같은 unified L3에 이미 존재하면 짧은 local path로 처리될 수 있다. 반면 write-sharing 데이터는 line의 ownership을 이전하고 다른 코어의 copy를 invalidate해야 하므로 payload가 작아도 control traffic과 acknowledgement가 병목이 될 수 있다. unified L3가 이런 coherence traffic을 없애는 것이 아니라, 같은 CCD 안에서 처리할 수 있는 후보의 범위를 넓히는 것으로 이해해야 한다.

5. CCD와 IOD의 분리

Zen 3 client chiplet과 EPYC 7003은 모두 compute die와 I/O 기능의 분리를 이해해야 하지만, 물리적인 구성과 노출되는 topology는 제품군에 따라 다르다. EPYC 7003은 Zen 3 compute die들을 DDR4 memory channel, PCIe와 외부 link를 담당하는 platform I/O에 연결하는 서버 제품군이다. AMD EPYC 7003 공식 페이지는 제품군을 DDR4/PCIe 4 세대 플랫폼으로 설명하고 최대 64코어 제품을 제시한다.

개념적인 memory miss 경로는 다음과 같다.

core in unified CCX
    -> L1/L2 lookup
    -> shared L3 lookup
    -> miss / home selection
    -> Infinity Fabric
    -> memory controller in I/O domain
    -> DRAM

이 경로에서 unified CCX는 local L3 lookup의 범위를 정의하고, IOD는 memory/I/O service의 경계를 정의한다. 같은 package 안의 다른 CCD라고 해서 unified CCX의 local access가 되는 것은 아니다.

6. Software와 topology

운영체제는 보통 CPU logical processor, core, package와 NUMA node를 노출하지만 내부 CCX 또는 exact L3 home을 항상 동일한 수준으로 노출하지는 않는다. 따라서 다음 정보를 함께 확인해야 한다.

확인 항목	질문	활용
CPU topology	어떤 logical CPU가 같은 core·CCD·NUMA node에 속하는가?	thread affinity와 실험군 구성
cache topology	L3 공유 범위가 어떻게 표시되는가?	shared working set 배치
NUMA distance	local과 remote memory의 거리는 얼마인가?	page placement와 first-touch 정책
firmware setting	NPS와 memory interleave가 어떻게 설정되었는가?	EPYC memory locality 해석
측정 counter	core, L3, fabric, memory controller의 traffic은 얼마인가?	원인이 cache인지 service인지 분리

lscpu -e, lscpu -C, numactl --hardware, numactl --show는 OS가 노출하는 topology를 확인하는 출발점이다. Linux perf와 AMD uProf는 cache·memory·fabric 관련 단서를 제공할 수 있지만, 내부 unified CCX queue나 모든 route를 복원하는 도구로 간주해서는 안 된다.

비교/분석

1. Zen 2와 Zen 3 cache grouping

분석 축	Zen 2	Zen 3
shared L3 group	4코어 CCX당 16MB	최대 8코어 unified group당 32MB
CCD 내부 경계	두 CCX 사이에 추가 경계	하나의 주요 L3 group으로 단순화
같은 CCD의 shared data	producer와 consumer가 CCX를 넘을 수 있음	같은 unified group 안에 배치할 여지가 큼
다른 CCD의 shared data	CCD/fabric remote	CCD/fabric remote
memory access	L3 miss 후 IOD/memory service	L3 miss 후 IOD/memory service
scheduler 관점	CCX와 CCD affinity를 모두 고려	CCD affinity와 L3 contention을 우선 고려
주의점	CCD 합계 32MB를 단일 32MB local cache로 보면 안 됨	32MB unified L3를 전체 socket cache로 보면 안 됨

2. 접근 범위별 비용 모델

접근 범위	대표 경로	추가 비용의 원천	실험에서 고정할 항목
같은 코어	core → L1/L2	private cache miss와 pipeline stall	working-set size, load/store 비율
같은 unified CCX	core → shared L3	L3 lookup과 group contention	같은 CCD, 동일 L3 group 배치
Zen 2의 다른 CCX	core → local fabric → other CCX L3	CCX 경계, coherence와 queue	두 CCX에 thread를 분산
다른 CCD, 같은 socket	source CCD → fabric/IOD 또는 package path → target CCD	die-to-die hop, IOD/fabric queue	CCD affinity, address placement
같은 socket memory	CCD → fabric → IOD → MC → DRAM	IOD queue, MC scheduling, DRAM timing	NPS, channel interleave, read/write 비율
다른 socket memory	local CCD/IOD → socket link → remote IOD → DRAM	remote NUMA, link retry와 remote service	CPU·memory binding, socket distance

Unified CCX의 효과는 세 번째 행의 Zen 2 다른 CCX 접근을 두 번째 행에 가까운 분석 단위로 이동시키는 데 있다. 네 번째 행 이후의 비용은 unified L3가 직접 제거하지 않는다.

3. Workload별 해석

workload	unified CCX에서 기대할 이점	남는 병목	측정 지표
private-cache 계산	제한적	L1/L2 miss, execution dependency	IPC, L1/L2 miss, core stall
read-mostly shared data	같은 CCD의 shared L3 hit 가능성 증가	L3 capacity와 contention	L3 hit ratio, loaded latency
producer-consumer	같은 unified group에 배치하면 경계 감소	synchronization과 queue	hand-off latency, p95/p99
write-sharing lock	같은 CCD의 remote-group hop 감소 여지	ownership, invalidate, ack	line migration, coherence traffic
streaming memory	L3 group 통합의 효과가 작음	IOD, MC와 DRAM bandwidth	sustained bandwidth, MC occupancy
multi-socket NUMA	unified local group의 이점은 유지	socket link와 remote memory	remote ratio, NUMA latency

4. 지연과 처리량의 개념식

제품의 내부 cycle 수를 알 수 없을 때는 측정 경계를 다음처럼 분리한다.

L_same_unified = L_L1/L2_miss
               + L_unified_L3_lookup
               + L_L3_contention
               + L_response

L_remote_CCD = L_L1/L2_miss
             + L_local_L3_lookup
             + L_home_or_coherence
             + L_IF_forward
             + L_remote_L3_or_IOD_service
             + L_response
             + L_queue_retry

L_same_unified가 낮아질 수 있다는 설명은 구조적인 분석 가설이지 모든 workload에서 보장되는 benchmark 결과가 아니다. 실제로는 unified L3 contention, cache state, address home, fabric load와 frequency state를 함께 기록해야 한다.

공유 service가 있는 chiplet 시스템의 sustained throughput은 다음 상한으로 생각할 수 있다.

B_sustained <= min(sum of CCX injection capacity,
                   CCD/fabric capacity,
                   IOD gateway capacity,
                   memory service capacity)

여기서 sum of CCX injection capacity는 코어가 요청을 생성하는 능력을 뜻하며, 각 capacity가 독립적으로 합산된다는 뜻은 아니다. 여러 unified CCX 또는 CCD가 같은 IOD, memory controller와 response path를 공유하면 공통 cut의 capacity가 상한이 된다.

5. 실험 설계

동일한 cache capacity라도 grouping 효과와 단순 용량 효과를 분리하기 위해 다음 실험을 사용한다.

동일 unified CCX 안에서 private-cache와 shared-cache access를 비교한다.
Zen 2에서는 두 CCX에 producer와 consumer를 나누고, Zen 3에서는 같은 CCD의 코어에 대응시킨다.
같은 CCD와 다른 CCD에서 동일한 access pattern을 실행한다.
local memory와 remote NUMA memory를 CPU·memory binding으로 분리한다.
read-mostly, write-sharing, lock contention과 streaming을 별도 workload로 측정한다.
평균뿐 아니라 p50/p95/p99, L3 miss, fabric traffic, MC queue와 power state를 기록한다.

동작 원리

1단계: 코어가 요청을 생성한다

load/store가 L1과 L2에서 hit하지 않으면 코어의 cache controller가 physical address, access type, ordering과 coherence attribute를 포함하는 transaction을 만든다. 요청은 먼저 local cache complex의 injection queue에 들어간다. miss 감지, L3 lookup 시작과 fabric 주입을 하나의 latency로 합치지 않아야 한다.

2단계: Unified L3를 조회한다

Zen 3의 unified complex에서는 최대 8코어가 공유하는 L3 group이 첫 번째 주요 shared-cache 경계다. 주소가 L3에 있고 필요한 permission을 얻을 수 있으면 data와 line state가 같은 CCD 안에서 반환될 수 있다. 이때 다른 코어가 같은 line을 사용하고 있으면 cache state와 arbitration에 따른 대기가 추가된다.

Zen 2에서는 요청 코어가 속한 4코어 CCX의 L3가 우선적인 locality 경계다. 다른 CCX에 line이 있으면 같은 CCD 안에서도 추가적인 CCX 간 fabric과 coherence transaction이 필요할 수 있다. Zen 3의 unified 구조는 이 CCX 간 분리 경계를 같은 L3 group 안에서 단순화한다.

3단계: L3 miss와 home을 결정한다

local unified L3에 line이 없거나 permission이 부족하면 주소 mapping과 coherence metadata가 다음 service domain을 선택한다.

destination = {
    source_core,
    source_ccd,
    l3_or_home_agent,
    target_ccd_or_iod,
    memory_controller_or_io,
    request_class,
    coherence_state
}

실제 home hash, directory와 probe-filter 구조는 제품별로 공개 수준이 다르다. 코어 번호나 단순한 물리적 위치만 보고 항상 특정 CCD 또는 memory controller를 예측하지 않고, firmware topology와 address sweep을 함께 사용한다.

4단계: Remote CCD 또는 IOD로 전달한다

다른 CCD의 cache line, DRAM 또는 PCIe service가 목적지라면 request가 CCD 밖의 fabric으로 주입된다. fabric은 request header뿐 아니라 data, response, coherence control과 ordering traffic도 운반한다. 수신 buffer나 link credit이 부족하면 backpressure가 source CCD의 injection queue까지 전파될 수 있다.

이 단계에서 확인할 항목은 다음과 같다.

unified CCX와 CCD별 request injection 및 response busy time
link 또는 gateway queue occupancy와 credit stall
data, snoop, invalidate, ownership acknowledgement의 비율
remote CCD와 IOD service의 p95/p99 latency
memory controller queue, channel utilization과 read/write 전환
corrected error, retry와 power-state transition

Unified CCX가 있다는 사실만으로 모든 CCD가 직접 연결된다고 가정하지 않는다. 제품별 topology가 공개되지 않았다면 source CCD → package fabric/IOD → target service를 대표 모델로 표시하고, exact route는 측정 또는 공식 block diagram으로 확인한다.

5단계: Coherence transaction을 완료한다

read access에서 다른 cache가 최신 data를 가지고 있으면 home/coherence service가 owner 또는 sharer에서 data를 전달하도록 조정한다. write access에서 exclusive ownership이 필요하면 다른 sharer의 copy를 invalidate하고 acknowledgement를 수집한다. 이 control traffic은 data payload와 별도로 fabric bandwidth와 queue를 사용한다.

Unified L3는 같은 CCD 안에서 이런 판단에 참여하는 cache group을 단순화할 수 있지만, coherence state machine을 없애지 않는다. 특히 lock과 false sharing workload는 동일 unified group에 배치해도 line ownership이 반복해서 이동하면 높은 tail latency를 보일 수 있다.

6단계: Memory service를 수행한다

cache hierarchy에 line이 없으면 IOD 또는 SoC memory domain의 memory controller가 address mapping에 따라 channel, rank, bank와 row/column service를 선택한다. 요청은 다른 CCD의 요청과 controller queue에서 경쟁하고, DRAM timing과 read/write turnaround의 영향을 받는다. 그러므로 unified L3 locality 개선과 DRAM bandwidth 개선을 동일한 효과로 표현하지 않는다.

7단계: 응답을 반환하고 배치를 검증한다

data 또는 coherence acknowledgement가 request ID와 ordering rule에 따라 source core로 돌아오면 cache state와 replacement metadata가 갱신된다. 배치 효과를 확인할 때는 다음 비교를 같은 조건에서 수행한다.

same unified CCX
    vs same CCD, different logical group when applicable
    vs different CCD, same socket
    vs remote NUMA node

각 실험에서 thread affinity, page placement, working-set size, core frequency, SMT, memory interleave와 background traffic을 기록한다. unified CCX의 구조적 이점을 주장하려면 단일 평균 latency보다 access distribution과 p99를 함께 제시해야 한다.

장단점

장점	단점 및 주의점
최대 8코어가 하나의 L3 group을 공유해 CCD 내부 shared-data locality를 단순화	unified L3 용량과 tag/data port를 더 많은 코어가 함께 경쟁할 수 있음
Zen 2의 두 CCX 사이에 있던 같은 CCD 내부 경계를 줄임	다른 CCD, IOD와 socket 접근의 remote 비용은 남음
producer-consumer와 read-mostly sharing을 같은 CCD에 배치하기 쉬움	scheduler가 CCD와 L3 contention을 무시하면 이점이 사라질 수 있음
32MB L3를 두 개의 16MB CCX로 나누지 않고 하나의 working set group으로 활용	unified L3가 전체 socket에 공유되는 cache라는 뜻은 아님
compute die를 반복 조합하는 chiplet 전략과 cache locality 개선을 함께 제공	fabric, coherence, IOD queue와 die-to-die traffic의 검증이 필요함
Zen 3 EPYC와 client 제품의 core grouping을 설명하는 유용한 모델	제품별 core disable, cache 구조와 topology를 고정된 규칙으로 일반화할 수 없음
같은 CCD의 일부 synchronization traffic을 줄일 여지가 있음	write-sharing, false sharing과 ownership migration은 여전히 비용이 큼

선택과 검증 기준

unified CCX를 전체 CPU의 단일 shared cache로 쓰지 말고 CCD 내부의 L3 locality group으로 정의한다.
Zen 2의 4코어 CCX 두 개와 Zen 3의 unified 8-core complex를 같은 cache grouping으로 비교하지 않는다.
shared-data workload는 같은 unified group, 다른 CCD와 remote NUMA를 분리해 측정한다.
L3 hit ratio와 cache latency를 DRAM bandwidth 또는 application throughput과 혼동하지 않는다.
write-sharing에서는 data bytes뿐 아니라 invalidate, ownership과 acknowledgement traffic을 측정한다.
EPYC의 core 수, CCD 수와 memory channel 수를 fabric의 sustained capacity로 바로 환산하지 않는다.
실제 benchmark에서는 lscpu, numactl, perf, AMD uProf와 firmware topology를 사용하되 내부 exact route를 추정하지 않는다.
평균 latency가 좋아져도 L3 contention, IOD queue 또는 remote access의 p95/p99가 악화되지 않았는지 확인한다.

핵심 정리

AMD Zen 3 Unified CCX는 최대 8코어가 하나의 32MB L3 group을 공유하는 CCD 내부 locality 모델이다.
Zen 2의 4코어 CCX 두 개와 비교하면 같은 CCD 안의 shared-data와 coherence 경계가 단순해진다.
Unified L3는 다른 CCD, IOD, DRAM과 socket의 remote latency를 제거하지 않으며 전체 CPU shared cache를 의미하지 않는다.
성능 분석은 local L3 lookup, L3 contention, coherence traffic, fabric traversal, IOD·memory service와 NUMA placement를 분리해야 한다.
실제 이점은 workload 배치와 cache state에 의존하므로 평균값뿐 아니라 L3 miss, fabric/MC queue와 p95/p99를 함께 측정해야 한다.