Ch 3: 메모리 일관성 모델 — HDM-DB·HDM-D·Bias·BISnp

#한 줄 요약

“Type 2 가속기의 device memory는 host와 device 양쪽이 캐시할 수 있어 일관성 메커니즘이 필요합니다.” — CXL은 두 가지 모델을 정의합니다. HDM-D는 Bias 전환으로 snoop 오버헤드를 회피하고, HDM-DB는 Back-Invalidation Snoop으로 device가 host cache를 명시적 무효화합니다. Bias가 경량 위주라면 BISnp는 정확성 위주입니다.

Ch 2에서 Type 2 가속기가 양방향 cache coherent하다는 걸 봤습니다. 이 장은 그 일관성이 어떻게 유지되는지를 분해합니다. 핵심은 *HDM (Host-managed Device Memory)*의 두 가지 변형입니다.

#HDM이란

*HDM (Host-managed Device Memory)*은 디바이스의 메모리를 host의 system physical address (SPA) 공간에 매핑한 영역입니다. host CPU의 load·store instruction이 직접 device 메모리에 도달합니다.

Type 3 메모리 expander의 모든 메모리가 HDM입니다. Type 2 가속기는 attached 메모리의 일부 또는 전부를 HDM으로 노출합니다.

#HDM-D vs HDM-DB

CXL은 HDM을 두 가지 변형으로 정의합니다.

HDM-D는 single-owner 가정. HDM-DB는 multi-owner 가정. 이 두 패턴에 서로 다른 메커니즘을 적용하는 게 CXL의 효율성 비결입니다.

#HDM-D — Bias 기반 일관성

HDM-D 영역은 Bias 모드가 Host Bias 또는 Device Bias 중 하나에 있습니다.

Bias 전환은 software가 trigger합니다. LLM inference 시나리오에서:

Bias 전환 자체는 수 µs가 들지만, 적절한 bias 동안의 access는 snoop 없이 빠릅니다. 큰 phase가 바뀔 때만 전환하는 게 권장.

#HDM-DB — BISnp 기반 일관성

HDM-DB는 Back-Invalidation Snoop (BISnp) 메커니즘을 씁니다. CXL 3.0부터 추가됐습니다.

핵심 아이디어:

• Device가 host의 cache를 명시적으로 무효화하는 메시지를 보낼 수 있음
• Host cache의 stale 데이터가 device update를 못 본 채 사용되는 것을 방지

BISnp 시나리오 (Device-Bias HDM-DB 영역에 host가 접근):

BISnp가 필요한 이유는 device가 자기 캐시를 update했을 때 host의 stale 캐시를 무효화해야 데이터 무결성이 유지되기 때문입니다.

#Bias vs BISnp — 언제 어느 쪽?

LLM training 같은 명확한 weight/compute/output phase는 HDM-D가 효율적. shared in-memory database 같은 동시 다중 owner는 HDM-DB가 필요.

#Snoop Filter — Device 측 최적화

BISnp가 모든 cache line마다 발생하면 부담이 큽니다. Device는 snoop filter로 host가 어떤 cache line을 hold하고 있는지 추적해 불필요한 BISnp 회피합니다.

snoop filter의 크기·hit rate가 Type 2 디바이스 설계의 핵심 파라미터. 너무 작으면 false snoop이 늘고, 너무 크면 die area 낭비.

#Linux 측 — cxl-cli에서의 노출

CXL 디바이스가 HDM-DB·HDM-D 중 어느 변형을 지원하는지는 capability 표시로 노출됩니다.

1
$ cxl list -m mem0 -i
2
{
3
  "memdev":"mem0",
4
  "ram_size":274877906944,
5
  "capabilities": {
6
    "hdm_dynamic_capacity": true,
7
    "hdm_dc_back_invalidation": true,   # BISnp 지원 (HDM-DB)
8
    "hdm_dc_bias_mode": false           # Bias 미지원 (Type 3는 보통)
9
  }
10
}

Type 3 memory expander는 보통 BISnp만 또는 별도 일관성 메커니즘 없음 (host 단독 caching). Type 2 가속기가 Bias 또는 BISnp 또는 둘 다를 노출합니다.

#자주 하는 실수

#”BISnp가 Bias보다 항상 좋다”

아닙니다. BISnp는 매 access마다 동적 invalidation 가능성이라 워크로드 phase가 명확하면 Bias의 snoop-free access가 훨씬 빠릅니다. 워크로드 패턴 분석이 우선.

#”Bias 전환은 단순한 flag”

OS·driver·application 협조가 필요합니다. CUDA·ROCm·oneAPI의 고수준 API가 bias hint를 드라이버에 전달하고, 드라이버가 device로 전환 명령을 보냅니다. 단일 instruction이 아님.

#”HDM-DB는 host가 어디든 빠르게 접근 가능”

아닙니다. BISnp 메커니즘은 동작은 정확하지만 지연 페널티가 있음. cache line ping-pong (host·device가 같은 line 번갈아 update)이 발생하면 throughput이 무너집니다.

#”Snoop filter가 크면 무조건 좋다”

die area·power 비용이 큼. filter hit rate와 false snoop 빈도의 균형점이 워크로드 의존. 일반화된 best size 없음.

#”Type 3는 BISnp 신경 안 써도 됨”

거의 그렇지만 일부 Type 3가 device-internal cache를 가질 수 있고 (rare), 그 경우 BISnp 지원이 필요합니다. cxl-cli capability 확인이 권장.

#정리

• *HDM (Host-managed Device Memory)*는 device memory를 host SPA 공간에 매핑한 영역입니다.
• HDM-D는 device-owned — Bias 모드 전환으로 snoop 회피. 워크로드 phase 명확할 때 효율적.
• HDM-DB는 device-backed — BISnp로 device가 host cache를 명시적 무효화. multi-owner·shared 영역에 적합.
• Bias 전환은 software trigger, BISnp는 hardware-driven dynamic.
• Snoop filter가 Type 2 디바이스 설계의 핵심 — false snoop과 die area의 균형.

#다음 편

Ch 4: Pooling·GFAM·Fabric — Multi-host 메모리 공유에서 CXL 2.0 pooling과 3.0 coherent fabric, 그리고 *GFAM (Global Fabric Attached Memory)*가 어떻게 다중 host 메모리 공유를 가능하게 하는지를 본격적으로 분해합니다.

#관련 항목

• Ch 2: System Architecture — Type 1·2·3·MLD·MH-MLD
• Ch 8: CXL.mem — M2S·S2M·HDM Decoder — HDM Decoder의 mapping 구조
• HBM·GDDR 심화 Ch 10: CXL.mem 프로토콜 분해 — Bias·BISnp의 message 흐름

#시리즈 자료 출처 안내

본 글은 CXL Consortium 공개 자료·Linux drivers/cxl/ 소스·hyperscale 연구를 1차 자료로 합니다. CXL 4.0 Specification은 § navigation aid로만 인용. 자세한 spec 인용 정책은 Ch 1 footer 참고.