Ch 15: RAS·Performance·Compliance — 운용·검증의 마지막 단계

#한 줄 요약

“CXL 디바이스의 운용 신뢰성은 RAS 이벤트 4 등급·Poison list·CVME 모니터링·AER 통합으로 구성되고, Performance Considerations가 latency·bandwidth·QoS 예산을 정의하며, Compliance Testing이 상호운용성을 검증합니다.” — 이 셋이 production 도입의 마지막 관문입니다. 시리즈의 마무리 장입니다.

Ch 14에서 보안의 4 layer를 봤습니다. 마지막 장은 RAS·Performance·Compliance — 운용·검증의 핵심입니다.

#RAS 이벤트 4 등급

CXL 디바이스의 RAS 이벤트는 4가지 등급으로 분류됩니다.

Linux 6.2+는 Failure 이상에서 자동 page offline + MCE 이벤트 트리거.

#Viral·AER·Recovery

이들이 CXL link error의 standard handling. Linux의 pci_error_handlers가 vendor common path.

#Poison List·Late Poison

Poison List는 device가 bad media를 기록하는 리스트입니다.

CXL 3.2부터 Late Poison 메커니즘이 추가됐습니다:

Late Poison이 recovery에 더 유리한 워크로드에 활용.

#CVME — CXL Virtual Memory Errors

CVME는 device 측 메모리 fault counting입니다.

CVME data가 long-term 모니터링·디바이스 교체 결정의 기반. Datacenter operator가 health trend를 추적.

#Performance Considerations

CXL Performance Considerations는 *spec Ch 13 (작년 추가)*에서 다루는 latency budget·bandwidth utilization·QoS 가이드입니다.

자세한 측정·튜닝은 Embedded Performance Engineering Ch 54.

#Roofline 적용

Performance Engineering Ch 7 Roofline의 Roofline model을 CXL.mem 워크로드에 적용:

대부분 AI workload는 memory-bound — Roofline의 inclined region에 위치. CXL.mem의 effective bandwidth가 bottleneck.

#CHMU — Hot-Page Monitoring Unit (CXL 3.2)

Roofline에서 CXL.mem이 bottleneck이라는 결론이 나오면, 다음 질문은 무엇을 로컬 DRAM으로 끌어올릴까입니다. 자주 쓰는(hot) 페이지는 로컬 DRAM에, 드물게 쓰는(cold) 페이지는 CXL에 두는 티어링이 핵심인데, 문제는 어떤 페이지가 hot인지를 어떻게 아느냐입니다. 기존에는 호스트가 page table의 access bit을 주기적으로 스캔하는 소프트웨어 휴리스틱에 의존했고, 이는 부정확하고 CPU를 먹었습니다.

CXL 3.2가 추가한 CHMU(Hotness/Hot-page Monitoring Unit)는 이 측정을 디바이스 하드웨어로 내립니다. 메모리 디바이스 안에 카운터를 박아, 실제 디바이스에 도달한 접근(호스트 캐시에서 처리된 hit은 제외)을 *software-configurable 단위(unit, 보통 page 이상)*로 셉니다.

동작은 단순합니다.

• 각 unit의 접근 수가 epoch 임계값을 넘으면 순환 Hotlist에 큐잉됩니다.
• 소프트웨어는 이 Hotlist를 폴링하거나 인터럽트로 받아, 해당 unit을 로컬 DRAM으로 *승격(promote)*합니다.
• 외부 프로파일러 없이 디바이스가 직접 telemetry를 OS에 올립니다.

Linux는 CHMU를 perf 드라이버로 노출하는 작업이 진행 중이고, QEMU에도 CHMU 에뮬레이션 패치가 올라와 있습니다. Ch 12에서 본 QEMU 환경이면 실 하드웨어 없이 hotlist 동작을 실험할 수 있습니다.

이 하드웨어 측정은 HBM Ch 8에서 본 hot/warm/cold KV cache 티어링을 추측이 아니라 측정으로 돌리는 토대가 됩니다.

#Compliance Testing

CXL Spec Ch 14 Compliance Testing은 디바이스가 표준에 부합하는지 검증합니다.

CXL 4.0의 추가 test case:

Compliance Mode DOE는 DOE channel 위의 표준 test routing. 모든 4.0 디바이스가 Compliance Mode를 지원하면 test infrastructure가 통일됩니다.

#실 운용 — cxl health·event log

운영에서 가장 자주 쓰는 명령:

1
# 1. 디바이스 health (mailbox opcode 0x4400)
2
$ cxl health -m mem0
3
{
4
  "memdev":"mem0",
5
  "health_status":"normal",
6
  "media_status":"normal",
7
  "life_used_percent":12,
8
  "temperature":42,
9
  "dirty_shutdown_count":3
10
}
11

12
# 2. Event Records (opcode 0x4500)
13
$ cxl monitor -m mem0
14
[2026-06-18 09:10:23] Info: Mailbox cmd 0x4400 completed
15
[2026-06-18 09:11:45] Warning: Correctable ECC error at 0x80045000
16
[2026-06-18 09:12:01] Failure: Media error at 0x80067800
17

18
# 3. Poison list
19
$ cxl list -m mem0 -P
20
{
21
  "poison":[
22
    {"address":"0x80012340", "length":64, "source":"injected"},
23
    {"address":"0x80067800", "length":4096, "source":"internal"}
24
  ]
25
}
26

27
# 4. bpftrace로 이벤트 빈도 추적
28
$ bpftrace -e '
29
  tracepoint:cxl:cxl_aer_correctable_error {
30
    @[probe] = count();
31
  }
32
  interval:s:60 { print(@); clear(@); }
33
'

#장기 추적 지표

운영에서 장기 추적할 5가지 지표:

Prometheus·Grafana 같은 모니터링 stack에 노출해 데이터센터 fleet 관리.

#자주 하는 실수

#”Failure event = 디바이스 즉시 교체”

Failure는 단일 영역 fault. page offline으로 격리가 우선. fleet-wide failure rate trend를 보고 교체 결정.

#”Compliance Mode DOE는 4.0 전용”

기본 mechanism은 3.x에도. CXL 4.0이 Compliance test routing을 표준화한 것. vendor implementation의 호환성 차이가 있을 수 있음.

#”CVME 데이터는 자동 분석”

Raw data가 host에 전달될 뿐, 분석은 software 측 책임. 모니터링 stack 구축이 필수.

#”Late Poison은 항상 좋다”

워크로드 의존. Data integrity가 critical하면 기존 즉시 reporting이 안전. Recovery 가능성·다운타임 비용을 비교 평가.

#”Roofline에서 CXL.mem이 bottleneck이면 무조건 더 큰 device”

Workload tuning이 먼저. cache hit rate↑·data locality↑·sequential access로 effective bandwidth 향상. device upgrade는 마지막 옵션.

#정리

• RAS 이벤트 4 등급은 Information·Warning·Failure·Fatal. Failure 이상에서 page offline 자동.
• AER·Viral·Recovery가 standard error handling. Linux pci_error_handlers가 common path.
• Poison list가 bad media tracking. Late Poison (3.2+)으로 recovery-friendly 모드 추가.
• CVME는 device 측 fault counting. CXL 4.0의 granularity 강화·Patrol Scrub event.
• Performance Considerations: latency budget·sustained bandwidth·QoS class.
• Roofline 모델 적용으로 memory-bound 워크로드의 bottleneck 식별.
• Compliance Testing: protocol·link·topology·security. Compliance Mode DOE가 4.0의 표준 routing.
• 장기 운영 지표: poison rate·life_used·dirty_shutdown·temperature·CVME.

#시리즈 마무리 — 15편 회고

본 시리즈는 CXL 4.0의 핵심 동작과 구현을 15편으로 풀었습니다.

*공개 자료 (CXL Consortium·Linux GPL·QEMU GPL·hyperscale 논문)*를 1차 자료로 사용하고, CXL 4.0 Specification은 § navigation aid로만 인용했습니다. spec 본문의 wording·table·figure 재생산 없음.

다음 단계의 CXL 깊이 학습은 기존 다른 시리즈에 분산 추가된 챕터들이 받습니다:

• HBM·GDDR 심화 Ch 9~12 — 메모리 산업 관점
• Embedded Performance Engineering Ch 54~56 — 성능 측정·튜닝
• Embedded Security Ch 11~13 — 보안 깊이
• Modern Embedded Recipes Ch 149~151 — 임베디드·implementation
• Bootloader Internals Ch 34~36 — 부팅·UEFI
• 4개 디버깅 시리즈의 CXL 추가 챕터들

#관련 항목

• Ch 1: CXL의 자리와 진화 — 시리즈 시작
• Embedded Performance Engineering Ch 54: CXL.mem 지연·대역폭 실측
• Memory Diagnostics Ch 6: CXL 메모리 진단
• Embedded Debugging Ch 9: CXL 디바이스 트러블슈팅
• Postmortem Debugging Ch 5: CXL 디바이스 Core Dump 분석

#시리즈 자료 출처 안내

본 시리즈는 CXL Consortium·DMTF·PCI-SIG 공개 자료·Linux drivers/cxl/ 소스 (GPL)·QEMU 소스 (GPL)·hyperscale 연구 자료를 1차 자료로 합니다. CXL 4.0 Specification (Revision 4.0, Version 1.0, August 13, 2025)은 § navigation aid로만 인용. spec 본문의 wording·table·figure 재생산 없음.

CXL® and Compute Express Link® are trademarks of the Compute Express Link Consortium, Inc. Spec 인용은 © 2019-2025 COMPUTE EXPRESS LINK CONSORTIUM, INC. ALL RIGHTS RESERVED.의 저작권을 따릅니다.