Donghyun Gouk, Sangwon Lee, Miryeong Kwon, Myoungsoo Jung (Computer Architecture and Memory Systems Laboratory) USENIX 2022 Annual Technical Conference
개요
CXL을 지원하는 FPGA하드웨어, 소프트웨어, 그리고 응용프로그램을 만들어서 테스트 해보고 CXL의 잠재력을 평가하였다.
Motivation
Memory disaggregation이 점점 확장성, 리소스 관리의 유용성과 같은 장점으로 인해서 관심을 받는 상황에서 RMDA와 같은 방식은 Latency측면에서 overhead가 심하기 때문에, 성능 저하의 큰 원인중 하나였다. CXL은 하드웨어 레벨에서 메모리 관리를 함으로서, 빠른 캐쉬 일관성 및 메모리 통신을 가능하게 하여, 이러한 시스템의 성능 향상의 큰 도움이 된다.
Importance
RDMA와 같은 경우에는 RNIC사이의 데이터 전송과 메모리 카피가 일반적인 Memory에 비해서 발생한다는 점과 그리고 Cache coherency를 맞추어 주기위해서 추가적인 소프트웨어적 방안이 필요한 점에서 성능의 오버헤드가 존재하였다.
Swap을 이용하여서 Disaggregate문제를 해결하는 방법들도 있지만, Page fault, I/O 처리, 스케쥴링 코스트등 여러 Overhead가 발생하였다. 또한 Swap방식은 메모리에 접근하기 위해서 DRMA를 사용하기 때문에 RDMA와 같은 문제가 발생한다는 문제도 있었다.
Key-value store와 같은 특수한 오브젝트 구조체를 사용하여서 Virtual address를 사용할 경우 생길수 있는 위의 문제들을 해결하고자 하는 방법들도 있었지만, page-based시스템과 시맨틱이 달라서, 이러한 변환과정에서 생기는 오버헤드와 Application을 Modification하는데 비용이 든다는 문제가 있었다.
이러한 상황을 해결하기 위해서 CXL이 개발되었지만, 논문이 나온 시점에서는 CXL이 Production level에 존재하지 않기 때문에, 성능 분석및 CXL의 활용방안에 대한 탐구가 부족한 상황이었다.
Main Idea
CXL하드웨어 부터 운영체제, 그리고 Usecase까지 만들어서 한번 CXL이 얼마나 유용한지 성능 향상은 어느정도 보일 수 있는지 테스트 해보자.
Design & Implementations
- BAR: Base address register
- HDM: Host-managed device memory
- USP: Upstream port
- DSP: Downstream port
- FM: Fabric manager
CXL and Memory
CXL과 같은 경우에는 RDMA처럼 Computing resource를 필요로 하지 않는다. CXL디바이스는 완전히 수동적인 모델로, CPU의 요청에 따라서 결과를 내보낸다. CXL은 PCIe에 구현되어 있으며, CXL컨트롤러가 Flits이라고 불리는 CXL의 패킷 (Request)를 DRAM Request를 바꾸어서 DRAM controller에 결과를 내도록 명령을 내린다. Figure 2에서 알 수 있듯이, 호스트 CXL은 여러개의 CXL root port를 가지고 있고, 각각의 Root port는 다시 여러개의 Endpoint device와 연결되어 있다.
- 메모리 Expender
- PCIe Initialization과정을 거치면 호스트와 디바이스는 Base-address-register와 HDM의 크기정보를 교환한다. 이를 이용해서 CXL Root port는 load/store 명령을 CXL flit으로 변환해서 CXL switch에 보내고 CXL switch는 수신인이 되는 CXL device의 Controller에 발송한다. 이를 통해서 디바이스의 CXL Controlller는 HDM에서 BAR 주소를 빼서 HDM의 Physical address를 얻고 얻은 주소를 바탕으로 Memory controller에 메모리 접근 요청을 날린다. 디바이스는 이 요청을 처리해서 다시 CXL flit으로 CXL switch에 보내지고 CXL switch는 이 요청을 요청의 수신인이 되는 Host cpu의 캐쉬에다가 올리는 방식으로 Memory expender가 구현된다.
- CXL switch
- Host의 RP는 CXL switch의 USP와 연결되고, CXL switch의 DSP는 CXL device와 연결되어 있다. CXL FM는 내부 routing table을 다시 쓰는 방식으로 CXL Switch의 USP와 DSP의 연결을 결정할 수 있다. 또한 CXL swtich는 가상의 Logical device를 만들어서 가상 논리 테이블을 만들어 CXL device들을 다양한 호스트 사이에 Sharging할 수도 있다.
Software runtime for CXL
CXL 메모리를 User space에 올리는 것은 Software runtime이 도움을 필요로 한다. 이를 위해서, DIRECTCXL는 HDM어드레스를 여러개의 Segment로 나누어서 cxl-namespace라는 단위로 만들고 그것들을 Application에다가 주는 방식을 사용하였다. CXL runtime은 Figure 4에서 볼수 있다 싶이, CXL디바이스들을 /dev에 나타나도록 하고 IOCTL로 접근하게 되면 MMAP과 같이 Virtual address space에다가 HDM을 올려주는 역활을 한다.
Prototype Implementation
프로토타입 구현에서는 4개의 호스트와 4개의 디바이스를 하나의 CXL swtich로 공유하도록 하였다. 16mm FPGA로 만들어진 CXL디바이스는 64GB의 램을 가지고 있도록 설계되었다. 또한 CXL을 서포트하는 Host RISC-V 기반의 Host cpu도 설계하였다. 이 Host cpu는 Last-level cache가 CXL RP로 사용할 수 있도록 설계되었다. 또한 이 호스트 프로세서는 리눅스 5.13과 DIRECTCXL runtime도 돌릴 수 있도록 설계되었다. CXL switch는 FM를 통해서 다양한 가상 논리 구조를 만들어 낼 수 있도록 하였다. 이외에도 구현하기 위해서 ACPI, MMIO와 같은 설계도 CXL 2.0규격에 맞추어서 처음부터 만들었다.
Result
- RDMA와 같은 경우에는 PCIe와 DMA가 2번 호스트 사이드와 디바이스 사이드에서 발생하고, Network코스트도 들어가지만 CXL과 같은 경우에는 한번만 메모리 읽기 요청, PCIe접근이 일어나고 네트워크 코스트가 없어서 대략 8.3배 빠른 메모리 Latency를 보였다.
- Payload사이즈가 커질수로 RDMA는 Memory copy코스트가 Latency의 주된 원인을 차지 하였고, CXL은 CPU LLC (CPU Cache)가 주된 Latency이 원인이 되었다.
- CXL에서는 CPU Cache처럼 기존의 RDMA에서는 무시할 수 있었던 CPU Cycles들도, 성능저하의 원인이 되었다. (빨라졌기 때문에)
- CDF를 그려보면 RDMA에서는 Network때문에 Tail latency가 길어지지만, CXL은 CPU Cache를 직접 사용함으로서, Tail latency가 Local과 비슷한 수준을 보였다.
- 현재 PCIe4에서 주된 Bottleneck이 PCIe 성능임으로, PCIe5로 올라가게 된다면, 성능이 더욱 좋아질 것이라고 예측 가능하다.
- Macro benchmark에서도 상당한 성능 향상을 보였다.
Contribution
- CXL이 아직 Production level로 출판되지 않음에도 풀 스택 구현을 통해서, CXL 성능 분석과 앞으로 연구의 진행방향을 제시함
Criticize
- RDMA는 CXL보다 좀더 Flexible하고 General한 디자인을 제공할 수 있다. (RMDA의 한계)
- Production level이 어느정도 인지는 FPGA프로토 타입으로만으로 정확히 알 수는 없다.
- 굉장한 Implementation과 정밀하고, 하드웨어 레벨의 깊은 이해의 성능 분석을 제공하고 있다.