🧩 CPU

Intel Ring 인터커넥트

개요

Intel Ring은 여러 CPU core, distributed LLC slice, system agent와 memory 또는 I/O agent를 고리 형태의 on-die interconnect로 연결하는 구조다. 공유 bus처럼 모든 노드가 하나의 매체를 경쟁하는 대신, ring stop을 지나며 요청을 전달하므로 서로 다른 구간에서 여러 전송이 진행될 수 있다. Core 수가 작거나 중간 규모인 제품에서는 mesh보다 router와 배선 제어가 단순하고 zero-load 비용을 낮추기 쉽다.

이 문서에서 말하는 Intel Ring은 특정 제품의 완전한 RTL 공개가 아니라 공개 die 분석과 측정, 그리고 Intel client CPU를 대상으로 한 reverse-engineering 결과를 합친 개념 모델이다. Ring의 노드 배치, packet class, lane 수, arbitration 세부 정책은 세대와 제품군에 따라 달라질 수 있다. 특히 Intel server 계열의 많은 코어 제품은 Ring이 아닌 mesh 계열을 사용하므로, "Intel CPU는 모두 Ring"이라고 일반화해서는 안 된다.

핵심 개념

1. Ring stop과 논리적 노드

Ring의 각 연결 지점은 ring stop 또는 이에 준하는 agent interface로 이해할 수 있다. Ring stop은 local core 또는 cache controller에서 나온 요청을 고리에 주입하고, 지나가는 packet의 destination을 검사하며, 목적지 packet을 local agent로 전달한다. 다른 packet은 다음 stop으로 계속 전송된다.

일반적인 개념 모델은 다음과 같다.

블록	역할	주의할 점
Core agent	L1/L2 miss, write, synchronization 요청 생성	core 실행 지연과 ring 지연을 구분해야 함
LLC slice	LLC의 물리적 일부와 해당 주소 범위의 home 역할	한 core의 private L3가 아니라 전체 LLC의 분산 slice임
Ring stop	local 주입, forwarding, destination 검사	제품별 stop 내부 구현은 공개 범위가 제한적임
System agent	memory controller, I/O, interrupt 등 uncore 경계 연결	모든 요청이 같은 agent로 향하면 hotspot이 될 수 있음
Ring lane	request, snoop, acknowledgement, data 등의 traffic 운반	lane과 sub-ring 구성은 세대별로 다름

Ring은 단순히 물리적인 선 하나가 아니다. 실제 동작에는 destination 선택, packet class 분리, ring stop의 local injection, flow control, arbitration, cache coherence ordering이 포함된다. 따라서 토폴로지는 Ring이어도 전체 시스템은 coherent fabric으로 동작한다.

2. Distributed LLC와 address home

현대 Intel Ring 계열에서는 LLC가 여러 slice로 분할되어 코어 주변 또는 ring stop에 분산 배치된다. 논리적으로는 하나의 공유 LLC지만, 물리적으로는 여러 slice가 각각 일부 set 또는 address region을 담당한다. 주소의 home slice는 제품별 hash 또는 address mapping으로 선택되며, 이 hash의 정확한 함수는 일반적으로 공개되지 않는다.

Core가 요청한 cache line이 local slice에 home이면 짧은 경로로 처리될 수 있다. 다른 slice가 home이면 요청은 ring을 따라 remote slice까지 이동하고, data 또는 coherence response가 다시 돌아온다. 따라서 LLC 용량만으로 접근 시간을 판단하면 안 된다.

다음 세 가지 locality를 구분해야 한다.

Core locality: 요청을 발생시킨 core와 home slice의 물리적 거리
Address locality: 주소 hash가 어느 LLC slice를 home으로 선택하는지
Traffic locality: 여러 core의 요청이 같은 slice, memory agent 또는 ring segment에 집중되는지

Hash가 slice 사용량을 균등하게 만들어도 core-to-home hop 수와 동시에 사용하는 ring segment는 균등하지 않을 수 있다. 반대로 가까운 slice에 접근하는 workload라도 여러 core가 같은 segment를 공유하면 queueing latency가 커질 수 있다.

3. Traffic class와 physical sub-ring

공개 reverse-engineering 연구인 Paccagnella, Luo, Fletcher의 USENIX Security 2021 논문은 Intel client CPU의 on-chip ring을 분석하면서 두 개의 독립적인 lane과 packet type별 physical sub-ring 구조를 보고했다. 논문에서 설명한 대표 packet type은 다음 네 가지다.

Packet type	주된 의미	혼잡 시 영향
Request	cache miss, read/write 등 요청	home slice와 memory 방향으로 이동
Snoop	다른 cache의 상태 확인 또는 coherence 질의	공유 데이터가 많을수록 증가
Acknowledge	coherence 또는 transaction 진행 확인	대역폭은 작아도 지연되면 진행을 막을 수 있음
Data	cache line 또는 응답 데이터 운반	긴 packet이 ring 점유 시간을 늘림

이 네 종류가 모든 Intel 세대에 동일하게 존재한다는 뜻은 아니다. 논문은 특정 client 세대에서 관찰 가능한 프로토콜을 reverse-engineer한 것이며, 제품 사양서가 모든 내부 ring을 규정하는 표준은 아니다. 다만 control traffic과 data traffic이 서로 다른 경로 또는 class로 분리될 수 있다는 점은 Ring의 성능과 보안을 이해하는 중요한 모델이다.

4. 양방향 경로와 hop count

양방향 Ring에서는 source와 destination 사이에 시계 방향과 반시계 방향 경로가 모두 있을 수 있다. 이상적인 균등 Ring에서 stop 수를 N이라 하면 최소 hop 수는 다음처럼 쓸 수 있다.

h(source, destination) = min(|i - j|, N - |i - j|)

균등하게 분산된 요청을 단순화해 보면 평균 hop은 대략 N/4, 최악 hop은 floor(N/2)에 접근한다. 실제 Intel Ring에서는 packet class별 lane, stop 배치, 방향 선택, pipeline stage, queue 상태가 함께 작동하므로 이 식은 구조적 경향을 보는 모델이지 제품의 cycle 수를 뜻하지 않는다.

두 경로의 길이가 같을 때 어느 방향을 선택하는지, congestion을 보고 우회하는지, 특정 traffic class에 방향 선호를 두는지는 구현별 정책이다. 따라서 "항상 가장 가까운 slice로 간다" 또는 "항상 시계 방향이다"라고 단정할 수 없다.

5. Arbitration과 in-flight 우선

Ring stop에는 local packet을 ring에 넣을지, 이미 ring 위를 이동 중인 packet을 다음 stop으로 보낼지 결정하는 arbitration이 필요하다. 공개 연구가 제시하는 핵심 동작은 다음과 같다.

Ring 위에 이미 있는 packet은 다음 stop으로 진행할 기회를 우선 얻는다.
Local agent의 새 packet은 사용 가능한 경로와 class 조건이 맞을 때 주입된다.
Request, snoop, acknowledgement, data가 별도 sub-ring 또는 lane을 사용하면 class별 경쟁이 분리될 수 있다.
목적지 도착, response 반환, flow-control 조건이 만족되어야 packet이 ring 자원을 놓는다.

In-flight packet을 새 packet보다 우선하면 한 stop이 local traffic으로 ring을 계속 막는 현상을 줄이고, 이미 진행 중인 coherence transaction의 deadlock 위험을 낮출 수 있다. 대신 특정 방향이나 class에 지속적으로 부하가 몰리면 fairness와 tail latency 문제가 남는다. 정확한 round-robin, age-based, credit 정책은 제품별 내부 구현으로 공개되지 않은 경우가 많으므로, Intel Ring 전체의 고정 arbitration 알고리즘으로 표현해서는 안 된다.

6. Ring과 coherence의 경계

Ring은 cache coherence protocol 자체가 아니라 coherence message를 운반하는 fabric이다. Home LLC slice 또는 coherence agent는 다음을 판단한다.

요청 line의 현재 state와 sharer 또는 owner
다른 core에 snoop 또는 invalidate가 필요한지
data를 memory에서 읽을지, 다른 cache에서 forward 받을지
acknowledgement를 언제 반환할지

결과적으로 cache miss 시간은 ring hop latency만으로 결정되지 않는다. LLC lookup, snoop fan-out, data forwarding, memory controller queue와 response ring traversal이 모두 포함될 수 있다.

비교/분석

토폴로지 비교

항목	공유 Bus	Intel Ring	2D Mesh
기본 경로	하나의 공유 매체	인접 ring stop의 고리	인접 router의 격자
평균 경로	짧지만 공유 arbitration 증가	stop 수에 따라 대략 `N/4` hop	위치와 routing에 따라 여러 hop
최악 경로	매체 경쟁에 종속	양방향 균등 모델에서 `floor(N/2)` hop	mesh diameter에 종속
병렬성	제한적	서로 다른 구간에서 가능	여러 link와 path에서 높음
Bisection 경향	공유 매체 하나	고정된 cut이 구조적 제약	cut link 수가 커질 수 있음
비용	낮음	mesh보다 router·buffer가 단순할 수 있음	router, buffer, global wire 증가
주요 병목	공유 bandwidth와 arbitration	hop, ring segment, home slice hotspot	link hotspot, router queue, routing
적합한 규모	소수 agent	소·중규모 coherent core cluster	대규모 core와 많은 agent

동일한 링크 폭과 frequency를 가정하면 Ring의 가장 큰 장점은 적은 router 자원으로 여러 구간의 동시 전송을 제공하는 것이다. 그러나 Ring의 bisection capacity는 노드 수가 늘어도 같은 비율로 증가하지 않으며, 긴 경로와 shared segment가 tail latency를 키운다. 여러 physical ring 또는 lane을 추가하면 처리량을 높일 수 있지만 배선, 전력, arbitration과 검증 비용도 함께 증가한다.

Intel 제품군에서의 적용 범위

계열	Ring 관점	해석상의 주의점
Nehalem/Westmere	core와 shared L3를 연결하는 초기 multi-core ring bus 계열	세부 stop과 packet protocol은 제품별 공개 자료를 확인해야 함
Sandy Bridge~Broadwell client	distributed LLC slice와 core가 ring으로 연결되는 대표 client 구조	die 배치와 slice mapping은 세대별 차이가 있음
Skylake/Coffee Lake client	공개 연구에서 packet class, lane, contention 특성이 분석된 계열	연구 결과는 측정한 client 제품의 reverse-engineering 범위임
Skylake-SP 등 server many-core	mesh 계열로 설계 방향이 이동	client Ring 결과를 server mesh에 그대로 적용하면 안 됨
이후 제품	Ring, mesh, tile 또는 혼합 fabric이 제품군별로 공존 가능	제품 이름만으로 내부 topology를 추정하지 말 것

이 표는 세대의 모든 SKU를 분류하는 표가 아니라, Ring 문헌을 읽을 때의 경계 조건을 보여주는 표다. 특히 같은 microarchitecture 이름이라도 client와 server, core 수, cache 구성에 따라 fabric이 달라질 수 있다.

Hop latency 모델

Ring의 end-to-end 요청 지연은 다음과 같이 분해할 수 있다.

L_request = L_injection
          + h × L_hop
          + L_home_or_coherence
          + L_memory_or_data
          + L_return
          + L_queue

L_injection: core 또는 LLC agent가 packet을 만들고 ring에 주입하는 시간
L_hop: 한 stop에서 다음 stop으로 forwarding하는 pipeline 비용
L_home_or_coherence: home slice lookup과 snoop 또는 ownership 처리 시간
L_memory_or_data: memory controller 또는 다른 cache의 data service 시간
L_return: data와 acknowledgement가 source로 돌아오는 시간
L_queue: arbitration, class 경쟁, backpressure로 추가된 대기 시간

Zero-load에서 먼 LLC slice를 읽는 latency는 경로와 pipeline의 구조 비용을 보여준다. Loaded latency는 여기에 ring segment 사용률, home slice queue, in-flight packet 경쟁과 coherence traffic이 더해진 값이다. 따라서 벤치마크에서 LLC latency가 core 번호에 따라 증가하더라도 그것을 곧바로 DRAM latency나 전체 application 성능으로 해석하면 안 된다.

확장성 분석

Core 또는 stop 수가 늘어날 때 나타나는 주요 한계는 다음과 같다.

Diameter 증가: remote slice까지의 최단 경로와 최악 경로가 길어진다.
Segment sharing: 서로 다른 source가 같은 ring 구간과 목적지 queue를 공유한다.
Home concentration: hash가 균등해도 특정 memory agent 또는 coherence home이 hotspot이 될 수 있다.
Timing closure: 긴 global wire를 한 cycle에 처리하지 못하면 repeater 또는 pipeline stage가 필요하다.
Control traffic 경쟁: snoop과 acknowledgement가 data와 같은 자원을 사용하면 작은 control packet이 tail latency를 만든다.
Power and area 증가: 양방향 ring, 여러 class별 sub-ring, buffer와 arbiter가 추가된다.

이러한 비용이 parallel path와 higher bisection bandwidth의 이점보다 커지면 mesh 또는 계층형 tiled fabric이 더 적합할 수 있다. Ring이 Mesh보다 항상 느리거나 빠른 것이 아니라, core 수와 traffic matrix, LLC locality, coherence protocol, 목표 전력 예산의 함수로 선택된다.

동작 원리

1단계: Core miss와 packet 생성

Core의 L1 또는 L2에서 cache miss가 발생하면 cache controller는 주소, read/write 종류, ordering과 coherence 속성을 가진 transaction을 만든다. 요청은 해당 traffic class의 packet으로 변환되어 local ring stop의 injection queue에 들어간다.

이 시점에 측정해야 할 것은 core가 miss를 감지한 시각, injection queue에 들어간 시각, 실제 ring에 올라간 시각이다. 세 시각을 하나로 취급하면 L_injection과 L_queue를 구분할 수 없다.

2단계: Home LLC slice 선택

주소 mapping 또는 hash가 cache line의 home LLC slice를 선택한다. Home slice는 tag/state를 확인하고, line이 다른 cache에 있는지 또는 memory에서 가져와야 하는지 결정한다.

physical address
  -> slice/home selection
  -> source stop에서 방향 선택
  -> home LLC slice 도착
  -> snoop, data 또는 memory transaction

실제 slice hash는 제품별로 다를 수 있고 공개되지 않을 수 있다. 성능 분석에서는 core ID만으로 home을 예측하지 말고, PMU counter, controlled address experiment 또는 vendor topology 정보로 검증해야 한다.

3단계: 방향과 lane을 통한 전송

Source ring stop은 destination까지의 경로와 사용 가능한 traffic lane을 기준으로 packet을 전송한다. 양방향 경로가 있는 모델에서는 짧은 경로가 우선 후보지만, 동일 거리의 tie-break와 congestion-aware 선택은 구현별 정책이다.

각 stop에서 packet은 다음을 반복한다.

destination 또는 packet class를 검사한다.
목적지면 local agent에 전달하고, 아니면 다음 stop으로 forwarding한다.
다음 구간이 사용 가능하지 않으면 arbitration 또는 flow control에 따라 대기한다.
forwarding 중인 packet과 local injection 요청이 경쟁하면 in-flight traffic이 먼저 처리될 수 있다.

4단계: Coherence와 data service

Home slice가 line의 상태를 확인한 뒤 transaction은 여러 흐름으로 나뉠 수 있다.

다른 cache에 최신 data가 있으면 snoop과 data forwarding을 요청한다.
공유 상태를 바꾸어야 하면 invalidate 또는 ownership message를 보낸다.
어느 cache도 최신 data를 갖지 않으면 memory controller로 read를 요청한다.
요청을 마칠 수 있으면 acknowledgement와 data를 source core로 반환한다.

Snoop packet이 여러 stop을 순회하는 방식과 실제 coherence directory의 범위는 세대별로 다르다. Ring이 모든 core에 동일한 broadcast를 보낸다고 단정하지 말고, product documentation 또는 측정 대상의 protocol 모델을 확인해야 한다.

5단계: Arbitration과 backpressure

Arbiter는 적어도 local injection과 in-flight forwarding 사이의 순서를 결정한다. 다음 이벤트는 대기 시간을 증가시킨다.

같은 방향의 여러 source가 하나의 ring segment를 사용함
request와 data가 같은 physical resource를 공유함
home LLC slice 또는 memory agent의 입력 queue가 가득 참
coherence acknowledgement가 이전 transaction 완료를 기다림
ring stop의 local queue가 우선순위가 낮은 class로 분류됨

In-flight 우선은 ring을 계속 순환 중인 packet의 진행을 보장하는 데 유리하지만, local traffic이 지속적으로 주입되지 못하는 상황에서는 injection latency가 커질 수 있다. 따라서 성능 보고서는 평균 hop뿐 아니라 per-segment utilization, class별 queue occupancy, 최대 대기 cycle과 p95 또는 p99 latency를 함께 제시해야 한다.

6단계: Response 반환과 관측

Data와 acknowledgement가 source core로 돌아오면 request ID를 매칭하고 cache state를 갱신한다. 분석자는 다음 카운터 또는 실험 지표를 분리해 기록하는 것이 좋다.

관측 항목	질문
LLC slice hit/miss	home slice service가 병목인가?
local/remote slice latency	physical hop과 locality 비용은 얼마인가?
Ring segment utilization	어느 구간에 traffic이 몰리는가?
request/data/snoop 비율	payload보다 control traffic이 큰가?
queueing과 arbitration delay	loaded latency의 증가 원인은 무엇인가?
memory controller queue	Ring과 DRAM service를 구분했는가?
coherence forwarding	data가 memory가 아닌 다른 cache에서 왔는가?

장단점

장점	단점 및 주의점
mesh보다 적은 router 구조로 중간 규모 core를 연결하기 쉬움	stop 수가 늘면 평균·최악 hop이 증가함
여러 ring 구간에서 동시에 전송 가능	특정 segment, LLC home, memory agent에 hotspot이 생김
distributed LLC를 core 주변에 배치할 수 있음	LLC는 논리적으로 공유되어도 접근 latency는 균일하지 않음
양방향 경로로 평균 경로를 줄일 수 있음	방향 선택과 tie-break, traffic class 정책이 복잡해짐
packet class 분리로 control과 data 경쟁을 완화할 수 있음	여러 sub-ring과 lane은 배선·전력·검증 비용을 추가함
ring stop 기반 구조의 동작을 비교적 예측하기 쉬움	고코어 수에서 bisection과 diameter가 확장 한계를 만듦
구현 경쟁이 side-channel 관측 대상이 될 수 있음	Ring contention이 보안상 cross-core 정보 채널이 될 수 있음

보안 측면에서 USENIX Security 2021 연구는 ring contention을 이용한 cross-core covert channel을 단일 thread에서 4 Mbps 이상으로 구성하고, 암호 구현과 키 입력 timing을 추론하는 공격을 시연했다. 이 결과는 모든 Intel Ring 제품의 동일한 공격 성능을 뜻하지 않지만, interconnect contention도 microarchitectural observable state가 될 수 있음을 보여준다.

핵심 정리

Intel Ring은 core, distributed LLC slice와 uncore agent를 ring stop으로 연결하는 coherent on-die interconnect이며, LLC 전체는 논리적으로 공유되어도 접근 latency는 위치와 address home에 따라 달라진다.
양방향 Ring의 이상화된 최소 경로는 min(|i-j|, N-|i-j|)이며, stop 수가 증가할수록 평균 hop과 최악 hop, segment 경쟁이 함께 증가한다.
공개 reverse-engineering 연구는 Intel client Ring에서 request, snoop, acknowledgement, data traffic과 lane 또는 sub-ring 분리를 분석했지만, 그 세부를 모든 Intel 제품에 일반화할 수는 없다.
Arbitration에서는 진행 중인 packet과 coherence control의 forward progress를 보호하는 것이 중요하며, 실제 성능은 hop보다 queueing, home slice hotspot, memory service와 tail latency에 의해 악화될 수 있다.
Ring은 중간 규모에서 낮은 router 비용과 구간별 병렬성을 제공하지만, 코어 수와 global traffic이 커지면 mesh 또는 계층형 fabric이 더 나은 확장성 선택이 될 수 있다.