Ch 10: ARB/MUX — 세 프로토콜의 PHY 다중화

#한 줄 요약

“ARB/MUX는 Transaction Layer와 Physical Layer 사이에 위치하며, 세 프로토콜의 메시지를 같은 PHY로 시분할하는 CXL 고유 layer입니다.” — vLSM (virtual Link State Machine)이 protocol별 link state를 관리하고, ALMP가 protocol 협상·power transition을 제어합니다. PCIe에는 없는 component로, CXL이 protocol을 통합한 방식의 핵심입니다.

Ch 9에서 flit 단위 데이터 전송을 봤습니다. 이 장은 flit에 어느 protocol을 어떻게 packing할지 결정하는 ARB/MUX layer입니다.

#ARB/MUX의 위치

CXL의 protocol stack에서:

ARB/MUX는 CXL 고유입니다. PCIe에는 없는 layer로, CXL이 multi-protocol을 한 PHY로 통합한 방식의 핵심입니다.

#왜 ARB/MUX가 필요한가

세 프로토콜이 같은 PHY를 공유하려면 누가 언제 PHY를 쓸지 결정하는 arbiter가 필요합니다.

ARB/MUX는 protocol별 traffic profile을 알고 Flit packing 결정을 합니다.

#vLSM — Virtual Link State Machine

각 protocol마다 독립 link state를 관리:

세 protocol이 각자 vLSM을 가집니다. 한 protocol이 L1·L2에 들어가도 다른 protocol은 L0 유지 가능.

#ALMP — ARB/MUX Link Management Packet

ALMP는 protocol negotiation·power transition을 위한 control packet입니다.

ALMP는 flit 안에 packing되어 흐르되, 우선순위가 매우 높습니다. transmitter는 ALMP를 지연 없이 보냅니다.

#Arbitration Policy

ARB/MUX가 어느 protocol을 우선할지의 기본 정책:

이 정책은 기본 가이드. 디바이스·host implementation이 조정 가능합니다. 워크로드별 fine-tuning이 성능 차이를 만듭니다.

#Flit Packing 흐름

ARB/MUX의 한 flit 만들기 흐름:

Flit 가득 차지 않아도 latency 요구로 전송할 수 있음 (Latency-Optimized 모드).

#Bypass Feature

고급 모드로 ARB/MUX의 일부 결정을 생략합니다:

Bypass는 deterministic workload(예측 가능한 traffic pattern)에서 latency 절감에 효과적. 복잡한 mixed traffic에는 full ARB/MUX가 권장.

#L0p (4.0의 새 power state)

CXL 4.0의 L0p는 active 상태에서 일부 lane만 사용하는 state:

L0p의 가치:

• 유휴 워크로드에서 bandwidth 줄이고 power save
• L1 진입·복귀의 latency 페널티 회피
• 동적 dynamic scaling 가능

ALMP가 L0 ↔ L0p ↔ L1 전환을 협상합니다.

#CXL 4.0 vs 이전 — ARB/MUX 변경

ARB/MUX 자체는 대부분 그대로. 4.0의 추가:

근본 architecture 변경 없음 — backward compat 유지.

#Linux 측 — ARB/MUX 인식

ARB/MUX 자체는 firmware·hardware 결합으로 동작. Linux 측 직접 인식·제어 minimal. 다만 상태 monitoring 가능:

1
# CXL device state monitoring (vendor-specific)
2
$ cxl monitor -m mem0 | grep -i state
3
[2026-06-19 09:00:00] CXL.mem vLSM: L0
4
[2026-06-19 09:00:30] CXL.cache vLSM: L0 → L1 (idle)
5

6
# bpftrace로 ALMP 트래픽 추적 (vendor·platform 의존)
7
$ bpftrace -e 'kprobe:cxl_almp_send { @[arg1] = count(); }'

상세 동작은 device firmware·BIOS·platform OEM가 대부분 hide. 운영자는 상태 trend monitoring만 일반적.

#자주 하는 실수

#”ARB/MUX는 단순한 multiplexer”

정교한 arbiter입니다. 3개 protocol·여러 vLSM·power state·ALMP를 동시 관리. firmware 복잡도가 매우 높음.

#”Latency-critical 트래픽은 항상 1순위”

기본 policy는 그렇지만 워크로드별 조정 가능. bulk transfer 위주에서는 throughput에 우선순위를 줄 수도 있음. vendor firmware tuning.

#”L1·L2 entry는 자동”

ALMP 협상 필요합니다. 양 끝의 idle 인식과 state sync가 필요. protocol 별로 다른 시점에 idle.

#”ARB/MUX는 host·device 양쪽에 같은 implementation”

기능은 같지만 implementation 다름. Host의 ARB/MUX는 CPU 메모리 컨트롤러 내장, device는 별도 controller chip. Symmetric protocol·asymmetric implementation.

#”Bypass mode가 항상 빠르다”

Predictable workload에서만. Mixed traffic·dynamic workload는 full ARB/MUX가 더 안정적·결국 더 빠름. Bypass는 전문 workload tuning 영역.

#정리

• ARB/MUX는 Transaction Layer와 Physical Layer 사이의 multiplexer — CXL 고유 layer입니다.
• vLSM이 protocol별 link state 관리. L0·L0p·L1·L2·Disabled.
• ALMP가 protocol negotiation·power transition을 위한 control packet.
• Arbitration policy: snoop·response 1순위 → mem/cache request → io 순.
• Bypass Feature는 predictable workload에 latency 절감.
• CXL 4.0의 L0p state는 부분 lane active로 dynamic bandwidth scaling.

#다음 편

Ch 11: Linux drivers/cxl/ 분석 — Mainline kernel CXL 구현에서 Linux 6.x의 CXL subsystem 코드 구조와 probe 흐름을 본격적으로 분해합니다.

#관련 항목

• Ch 5: CXL 4.0의 핵심 새 기능
• Ch 9: Flit Format
• Ch 11: Linux drivers/cxl/ 분석

#시리즈 자료 출처 안내

본 글은 CXL Consortium·PCI-SIG 공개 자료를 1차 자료로 합니다. CXL 4.0 Specification은 § navigation aid로만 인용. 자세한 spec 인용 정책은 Ch 1 footer 참고.