1. CXL(Compute Express Link) 의 이해
CXL (Compute Express Link) 에 대해 급하게 알아야 할 듯하여,관련 자료들을 수집하고 학습.
- CXL(Compute Express Link) 란?
PCIe 기반으로 사용되어지는, 고속 DMA Controller 비슷할 것 같다.
즉 CPU 입장에서 생각하면, 각 Cache 에 연결된 AMBA(AHB,APB,AXI) 와 DMA를 이용하여 각 Memory 고속으로 전송하는 Bus Switch Interface가 맞을 듯 하다
- UCIe
CXL 기반으로 출발한 것 같으며, 현재 Chiplet이라는 ,즉 실리콘 즉 반도체에서 이를 다 연결하려고 하는 Interface가 맞을 것 같다.
- PCIe
PCI에서 발전된 Bus로 PCI/HPI는 직접 Driver를 개발했지만, PCIe 직접 개발해보지 못해 이 부분은 나중에 별도로 정리하도록 한다.
요즘은 솔직히 Kernel Platform화가 잘 되어있어, 개발보다는 주로 설정하고 변경하는 것이라 이 부분은 별도로 기회가 있으면 다시 정리하도록 하겠다.
- CXL 의 개인적 생각 과 결론
종합적으로 보면, CXL는 PCIe Interface 이용하지만, CPU 의 내부에서 비교하자면, AMBA(PCIe) 역할과 DMA Contorller 와 Memory Controller 가능 일 것이다.
그러니, CPU 밖에서, 다양한 CPU들 과 연결하는 것도 쉽게 가능 하리라고 본다.
더 나아가 왜 UCIe가 실리콘, 즉 반도체 위에서 한다는 이유도 대충 이해가 가는 듯하다.
1.1 CXL 구조 와 CXL Type
- CXL 구조 와 Type 의 이해
CXL에 대해 쉽게 설명이 되어 있어 , CXL 기본 구조 와 Type 1/2/3 쉽게 이해
CXL 2.0 이 후 Type1/2/3 기반으로 연결 확장 가능하며, 이를 다양하게 더 확장이 가능 설명
- CXL 의 Spec 과 이해
1.6 Flex Bus Layering Overview : Flex Bus 의 이해
2.0 Compute Express Link System Architecture : CXL의 Type1/2/3 의 이해
PDF의 좌측 Index 기반으로 각 살펴보면, 쉽게 감이 잡히는 듯하다
관련 그림들은 혹시 문제가 될 듯해서 가져오지 않음
Compute Express Link Consortium
- CXL 최신 Spec 신청가능하며 왠지 무료는 아닐듯?
- 일단 Spec 1.0으로만 만족
- CXL Device Type 1/2/3 구조 와 역할
| CXL Type | 포함 프로토콜 | 주요 역할 | 예시 디바이스 | 특징 |
|---|---|---|---|---|
| Type 1 | CXL.io + CXL.cache | 가속기(Accelerator) – 호스트 메모리를 캐시 형태로 접근 | Smart NIC, FPGA Accelerator, AI Inference Engine | 자체 메모리는 거의 없고, Host DRAM을 Cache Access 함 |
| Type 2 | CXL.io + CXL.cache + CXL.mem | 고성능 가속기 – Host 메모리 접근 + 자체 메모리 공유 가능 | GPU, FPGA with onboard HBM, AI Chip | 호스트와 디바이스가 서로의 메모리에 Coherent Access |
| Type 3 | CXL.io + CXL.mem | 메모리 익스팬더(Memory Expander) – Host에 추가 메모리 제공 | CXL.DIMM, CXL Memory Card, Persistent Memory | CPU가 Device 메모리를 Load/Store 식으로 사용 |
- CXL Controller 관점의 비교
각 Host 와 CXL Device(CXL Controller) 관점에서 비교를 해보자.
Cache 에 따라 성능이 변경되므로,
Coherency Directory 즉 Cache 의 일관성을 어디까지 해야 하는 지이며, 알고리즘은 어떤 것을 쓰는지 또, 범위는 어디까지 하는 지가 중요하다(이 부분 다시 밑에)
| 구성 요소 | Type 1 | Type 2 | Type 3 |
|---|---|---|---|
| CXL.cache | ✔ | ✔ | ✘ |
| CXL.mem | ✘ | ✔ | ✔ |
| CXL.cache | ✔ | ✔ | ✘ |
| Coherency Directory | (Host side only) | (Host + Device side) | (Host side only) |
| Local DRAM Access | ✘ | ✔ | ✘ |
| 목적 | Compute 가속 | Compute + 메모리공유 | Pure Memory 확장 |
- CXL Device Type1/2/3 확장 (결합)
CXL 2.0 이상부터는 이 Type 1/2/3 디바이스를 스위치와 Fabric구조에서 논리적 결합(Logical Device) 으로 묶을 수도 있다고 한다.
증권사 자료이지만, 이해 하기가 자료 좋음
- CXL Fabric 간단 정리
지능형 연결망이라고 하는데, 각 기능들을 Thread 즉 실로 보고, 이를 엮어서 각 기능들의 총체적인 기능을 말한다고 한다.
즉 CXL Fabric 구조는 여러 외부 CPU들 과 다양한 Peripherial 들 연결 확장까지도 생각을 해볼 수 있는 것이다.
1.2 CXL Swtich 구조
다양한 PCIe Channel 들을 처리하기 때문에 Arbiter/Mux 는 역할이 중요할 것 같으며,
즉, DMA Controller 역할이 비슷할 거라고 생각되어진다.
상위 Spec1.0 보면 다양한 기능들이 들어가면서, 다양한 기능들을 처리하려면, 단순한 DMA Controller가 아닌 복합적인 DMA Controller 동작할 거 같다.
CXL Switch 역시 여러 CXL Device Type 1/2/3 조합으로 각 CXL switch 마다 각 기능이 다 다를 것이다.
여러 CXL Device Type 1/2/3 조합이 가능하므로, 아래로 한정적으로 생각하지 말자.
 |
| CXL Switch Diagram |
- CXL 2.0 부터 추가되어진 기능
| 기능 | 역할 |
|---|---|
| Address Mapping / Routing | 어떤 요청이 어느 Type으로 가야 하는지 결정 |
| Coherency Management | 여러 Type 2/3 장치가 같은 주소 접근 시 캐시 일관성 유지 |
| QoS / Credit Flow | 트래픽 제어 및 우선순위 관리 |
| Memory Pooling / Partitioning | 여러 메모리 모듈을 하나의 논리 풀로 묶음 |
| Security (IDE) | 각 링크별 암호화 및 키 관리 |
1.3 Rambus 의 CXL Controller IP 확인
실제 CXL Controller IP 팔고 있는 곳이 있기에 관련 부분을 보도록 하자
- Data Encrytion 의 이해
AES의 대칭키 이해와 KEY 운영 GCM 확인
- CXL Controller IP기능 확인
- CXL Controller 3.1 vs CXL 2.0 비교
- CCIX(Cache Coherent Interconnect for Accelerators) Controller 각 기능
- CXL Controller -> 거의 이게 핵심
- PIPE 부분은 PCIe 와 같이 봐야 할 듯
- CXL 2.0 Controller 의 구조
- CXL 2.0 Controller
- CXL Protocol Layer
- User Interface Layer
- Integrity and Data Encryption (IDE) -> AES-GCM 방식
- Unique Features & Capabilities
- CXL 2.0 Controller with AXI Block
- ARM과 AMBA 호환
- Rambus CXL 2.0 Controller with IDE
- IDE(Encrytion)의 Zero Latency
- AES-256-GCM, GCM 이외 CTR 지원 가능?
- 상위와 CXL 2.0 Controller 와 동일
- PCIe 의 구조
- PCIe Contoller
- PCIe Switch
- PCIe Phy
CXL의 이해하려면 PCIe의 Phy를 사용하므로, 이 부분은 어 쩔 수 없이 봐야 할 듯하다
2. CXL 의 Cache 이해
CXL의 Cache 는 아주 중요한 개념이며, 어떻게 보면, CXL 성능 핵심 기능일 듯하다.
즉 Cache 알고리즘에 따라 각 CXL의 성능이 달라질 것이며, 이 부분은 거의 회사마다 민감한 문제가 있을 듯하다.
2.1 Cache Coherence 의 이해
- CPU 입장 의 SMP 관점
다중 코어의 cache-coherency protocols 이용하여 1개의 Core처럼 사용을 하려 한다면, 어떻게 해야 하지
- OS 입장의 SMP vs AMP 관점
OS 입장에서는 다중 코어일 경우, SMP vs AMP 어떻게 Scheduling 할 것인지, 즉 방법
Linux 의 경우, SMP기준으로 많이 사용
- CPU Cache Coherence 의 기본이해
각 독립적인 Cache를 Sync를 맞춰주는 작업이며, 아래 그림을 보면 쉽게 이해 간다.
그럼 Why 사용할까 , ARM 같은 다중 코어 일 때, SMP로 Task Scheduling 하려면, Cache Coherence의 역할은 중요하다
이유는 아래같이 여러 Core 같이 동시에 나누어서 작업을 해야 하기 때문이다.
 |
| https://en.wikipedia.org/wiki/Cache_coherence#Overview |
- Cache Coherence 의 문제
각 CPU Cache의 Coherence를 맞추어 주는 것은 좋으나, Cache Coherence의 범위를 예측을 못하는 문제가 발생하다.
SMP 기준으로 간단히 생각을 해보면,
모든 CPU의 Cache가 Coherence되어, 1/2번째 CPU는 작업을 나누어 완료 후, 3번째 CPU의 Cache 오래되어, 이제 필요가 없어지는 문제이다.
- Cache Coherence 의 개인 생각 정리
결과적으로, Cache Coherence 범위, Cache 사이즈 및 갯 수 정확하게 제대로 예측 못하면, Cache의 Hit 율이 계속 떨어지고 효율은 낮다.
어떻게 보면, Cache 예측과 Coherence 범위가 가장 중요할 듯 하다
좀 더 세부적으로 Cache Coherence 생각해보면, 아직 아래 Protocol도 이해를 못했지만,
Cache Coherence 운영을 하는 입장에서 생각을 해보면, 다음과 같은 생각도 얼마든지 해볼 수 있다.
- Cache Coherence를 3가지로 A.전체/B.부분(범위)/C.제외 이런 식으로 될 것 같기도 하다.
- 가중치(weight,bias)기반으로 매번 Cache Coherence 변경되어지거나 다양하게 생각 할 수 있을 것 같다.
- CNN으로 TinyML 사용해서, 가중치 대신해서 사용 가능 할 것 같다. (다양하게 생각이 듦)
이 부분은 Spec 과 나중에 Cache Corency Protocol 이해 후 다시 생각해 보고, 이해해보도록 하자
ESP32 Cache 와 Memory 비교
개인적으로 ESP32 CPU 설계를 잘했다고 생각을 하며, ESP-IDF 역시 너무 잘 구현을 해놨다.
2.2 Cache Corency Protocol
우선적으로 Cache Corency Protocol 이해 하기 위해서 각 Cache 상태들 부터 이해 해보도록 하자
머리가 나쁘면, 고생이다.
CAPI(Coherent Accelerator Processor Interface)
- Cache 의 상태 이해
| 상태 | 약어 의미 | 설명 |
|---|---|---|
| M | Modified / D / Dirty / DE / EM |
- 한 개의 캐시에만 존재하고 수정된(Dirty) 상태 - 메모리 내용은 오래된 값 (아직 반영 안 됨) - 교체 시 반드시 Write-back 필요 |
| O | Owner / SD / SM / T |
- 여러 캐시에 복사본 존재하지만 메모리는 오래된 값 - 한 캐시만 “소유자(Owner)” 역할 - 다른 캐시의 읽기 요청 시 Owner 캐시가 데이터 공급 |
| E | Exclusive / R / VE / EC / Me |
- 한 캐시만 데이터 보유하고 메모리와 동일(clean) - 다른 캐시에는 복사본 없음 - 쓰기 시 바로 M(Modified)로 전환 |
| S | Shared / V / SC |
- 여러 캐시에 동일 데이터 복사본 존재 - 주로 읽기 전용(Read-only) 상태 - 메모리와 일관됨 (clean) - 단, 일부 프로토콜(예: Dragon)은 Shared Clean이 dirty일 수 있음 |
| I | Invalid |
- 유효한 데이터 없음 (태그 불일치 또는 무효화됨) - 접근 시 메모리나 다른 캐시로부터 새로 읽어와야 함 |
Special / Extended States (MESI 확장형)
| 상태 | 이름 | 설명 |
|---|---|---|
| F (또는 R) | Forward / Recent |
- Shared 상태 중 대표 캐시(Forwarder)가 응답 역할 담당 - 동일 데이터가 여러 캐시에 있을 때 메모리 대신 이 캐시가 응답(intervention) - Intel: MESIF, IBM: R-MESI (MERSI) |
| H | Hover |
- 캐시에 주소 태그만 유지, 데이터는 무효(Invalid) - 버스에서 해당 주소가 탐지되면 빠르게 유효(S) 상태로 복귀 - HR-MESI, HRT-MESI 등에서 사용되어 검색 속도 개선 |
- Cache Status 요약 비교
| 상태 | 캐시에 존재 | 메모리 최신성 | 공유 가능성 | 쓰기 가능성 | 설명 |
|---|---|---|---|---|---|
| M | ✔ 있음 | ✘ 오래됨 | ✘ | ✔ | 수정됨, 아직 메모리 반영 안 됨 |
| O | ✔ 있음 | ✘ 오래됨 | ✔ | ✘ | 여러 캐시 중 한 곳이 최신 데이터 소유 |
| E | ✔ 있음 | ✔ 최신 | ✘ | ✔ | 유일한 캐시 복사본, clean 상태 |
| S | ✔ 있음 | ✔ 최신 | ✔ | ✘ | 여러 캐시에서 읽기만 가능 |
| I | ✘ 없음 | ✔/✘ 불명 | ✘ | ✘ | 데이터 없음 또는 무효 상태 |
| F | ✔ 있음 | ✔ 최신 | ✔ | ✘ | 공유 중 대표 캐시(Forwarder) |
| H | 태그만 존재 | ✘ | ✘ | ✘ | 주소만 남겨 빠른 재활성 가능 |
Cache Corency Protocol 의 종류 와 알고리즘
각 알고리즘의 흐름이 변경되어지는 것을 대충 알 수 있으며, 이 부분은 나중에 좀 더 확인하자.
MESI 의 이해 (대표적)
아직 완벽히 이해가 되지 않은 상태
MESIF 의 이해 (요즘?)
아직 완벽히 이해가 되지 않은 상태
https://en.wikipedia.org/wiki/List_of_cache_coherency_protocols#MERSI_(IBM)_/_MESIF_(Intel)_protocol
3. CXL 의 Linux Manual
현재 Linux를 잠시 보면, CXL는 Device Type 3으로 메모리 확장용 으로만 사용하는 듯하다.
- Linux Device Driver (CXL)
- CXL Linux Device Driver 와 Manual
- CXL Device Type 3으로만 사용?
CXL Device Type 3(Memory 확장용)로만 사용한 것 같으며, Manaul도 거기 까지 인듯하다.
- Linux UserSpace
- CXL Linux User Manual
- CXL ioctl 이용
3.1 CXL 의 Linux Kernel 소스
Linux Kernel 소스 찾아 각 부분 확인
- PCI의 ACPI 의 정보
다만 PCIe가 아닌 PCI 인듯하며, PM 제어는 오래전부터 존재 했던거 같다.
상위 CXL 1.0 Spec을 보면 PM제어는 부분이 많이 나온다.
- BIOS 와 ACPI 관련이해
BIOS 에서 사용하는 UEFI의 ACPI(Advanced Configuration and Power Interface)
- CXL 의 Core 소스 (Linux Kernel)
- 상위 Device Type 3 의 Memory 확장형 소스 인것 같음
- Memory 를 보면 주로 모듈형 RAM을 제어 DIMM
- CXL 의 이외 소스 (Linux Kernel)
- 상위 Core 기반으로 Memory 확장형에 ACPI 기술이 첨부
- UEFI 의 ACPI(Advanced Configuration and Power Interface)
- PCIe를 그냥 PCI로 기술을 하는 듯함
상위 Device Driver 와 각 Spec 1.0을 보면서 느낀 점을 정리하자면 아래와 같다.
- CXL Switch 의 개인생각
CXL 관련 Linux Kernel 소스 부분 확인 및 구조 확인 했지만, Device Type 3만 확인되는 듯하며,
CXL Switch Driver(각 CXL Type1/2/3 복합적 연결)는 아직 발견을 못했으며,
분명, USB Host 처럼 Bus 형태의 Driver 일 것 같은데, 현재 각 제조사마다 다 다를 테니 이것은 초창기 USB Host Controller와 비슷하게 갈 듯하다
또한, 분명히 CXL Switch가 구조화가 복잡하게 되므로, USB Host처럼 각 Device 의 구조를 설명하는 Description 형태로 각 설정을 변경하는 구조로 갈 듯하다. 왠지?
상위 부분은 Spec을 보고 나중에 다시 생각해보자
- CXL 기반의 AI 업체 개인생각
H/W 입장에서 보면, CXL기반의 AI 업체들의 핵심 개발은 왠지 CPU 와 GPU 와 NPU 의 CXL.cache 가 가장 중요할 듯 하다.
이유는 SRAM을 가장 효율적으로 빨리 동작 시켜서 DRAM기반으로 VRAM으로 성능 최적화를 하려고 할 것 같다.
S/W 입장에서 보면, NVIDIA처럼 이제 AI H/W 도 중요하지만, 오히려 S/W Platform의 다각화가 더 중요할 듯하다.
(NVIDIA 사이트만 가봐도 이해가 되며, Training 대충 경험이 있다면 이해가 더 빠르다)
3.2 Linux 의 Yocto
Yocto 기반의 Linux에서 CXL 관련부분 을 검색하고 자료 수집 하려 했으나, 아직 제대로 찾지를 못함
나중에 찾으면, 아래에 링크를 추가하겠음
- Yocto 의 기본이해
Yocto 의 기본이해
- Yocto 와 Kernel 관리
추후 다시 확인
- Yocto 의 openembedded Layer 확인
각 최신 버전 과 Layer 확인 했지만, 아직 발견 못함
CXL Switch 일 경우, 각 Bus Driver가 있어야 할 듯한데, 흐음?
3.3 Linux 의 QEMU
Linux Kernel에서 QEMU의 기반의 CXL 부분 확인
- QEMU 의 Linux Device Driver (CXL)
- CXL 전체 구조를 보면 역시 Device Type 3 메모리 확장형만 사용
- CXL 2.0 Type.1/2/3 지원 (문제는 Type 3만 사용)
- KERNEL CONFIG 확인
- QEMU 으로 동작되는 것을 확인
- 아래 링크 확인
