CXL-тестирование интерконнекта для дата‑центров нового поколения

На связи Максим Башмаков, руководитель отдела тестирования оборудования в Selectel. В своей лаборатории мы активно исследуем новейшие технологии и внедряем лучшее. Сегодня я хочу рассказать про CXL (Compute Express Link).

В сети есть несколько статей об этом интерконнекте. Однако конкретной информации про использование CXL в реальных кейсах мы не нашли. Обычному пользователю также наверняка будет интересно: как устройство выглядит в стойке непосредственно на сервере.

Краткая история CXL

Я не буду вдаваться в подробности истории CXL, в интернете и так достаточно информации о его развитии. Много сведений можно найти на сайте одноименного консорциума. Напомню только ключевые факты.

• Интерфейс CXL появился в 2019 году по инициативе Intel, Google, Cisco и других компаний для устранения «узких мест» в обмене данными между CPU, GPU и RAM. 
• Технология объединила преимущества PCIe с когерентной памятью, ускорив взаимодействие в гетерогенных системах. 
• Улучшенная производительность позволила эффективнее использовать ресурсы и нашла свое применение в центрах обработки данных, облачных и HPC-задачах. 
• Сегодня CXL — ключевой стандарт индустрии.

Было разработано несколько спецификаций: 

• CXL  1.0 и 1.1 — определяют интерфейс управления памятью, позволяя динамически распределять ее пулы между CPU и ускорителями GPU, FPGA и TPU;
• CXL  2.0 — расширяет возможности за счет поддержки пулов общей RAM, совместно используемых несколькими устройствами, а также введения переключателей CXL, которые упрощают топологию сети;
• CXL  3.0 — согласно заявленной спецификации, удваивает пропускную способность по сравнению с CXL 2.0, снижает энергопотребление и задержку, а также улучшает возможности построения архитектуры кластера CXL.

Что же такое CXL

Преимущество CXL — способность поддерживать когерентность кэша между процессором и подключенными устройствами. Иными словами: данные в кэше процессора и устройства всегда синхронизированы — нет необходимости в механизмах согласования, что и повышает производительность.

CXL также поддерживает различные режимы работы. Например, CXL.io обеспечивает высокоскоростную связь между процессором и дополнительным устройством, а CXL.mem предназначен для совместного использования памяти.

На схеме изображена многоуровневая архитектура CXL, которая отвечает за взаимодействие и обмен данными между компонентами. Рассмотрим уровни чуть подробнее.

CXL Transaction Layer (уровень транзакций) — обеспечивает обработку команд и данных, включает в себя:

• PCIe Transaction Layer — базовый уровень обработки транзакций;
• CXL.io для улучшения управление вводом‑выводом;
• CXL.cache и CXL.mem, которые предоставляют доступ к кэш-памяти и разделяемой памяти.

CXL Link Layer (уровень канала) — управляет обменом данных и обеспечивает надежность соединения, состоит из:

• PCIe Data Link Layer — стандартного канала PCIe;
• CXL.cache + CXL.mem Link Layer — улучшений для когерентного доступа к памяти и кэшу.

Flex Bus Physical Layer (физический уровень) — обеспечивает непосредственный обмен данных по шинам и содержит:

• PCIe/CXL Logical Sub-block — логическую часть совместного использования PCIe и CXL;
• PCIe Electrical Sub-block — физический интерфейс.

CXL ARB/MUX (арбитраж/мультиплексирование) — управляет совместным использованием интерфейса PCIe и CXL и распределяет между ними ресурсы.

Hardware

Рассмотрим подробнее, какие случаи использования можно найти в реальных устройствах. Один из примеров — CXL-экспандер, то есть расширитель оперативной памяти. Это PCIe-плата, на которой работает чип CXL. С помощью ее мы можем подключить дополнительный пул оперативной памяти.

На снимке выше — CXL‑экспандер с двумя DIMM‑слотами, поддерживающий ECC‑модули RAM объемом до 128  ГБ и работающий по интерфейсу PCIe  Gen 5  x8. При этом не только увеличивается объем оперативной памяти сервера, но появляются и другие преимущества.

Экспандеры — это только вершина айсберга. Есть много периферийных устройств, которые позволяют использовать CXL, в том числе и для отладки.

Уже началась интеграция чипов CXL в крупные проекты. Например, Lenovo SR860  V3 в сотрудничестве с компанией ASTERA LABS разработали платформу, способную вместить 96  модулей DIMM до 512  ГБ каждый, что в сумме дает почти 50  ТБ оперативной памяти! Однако главное — это даже не объем. Платформа может делиться этой памятью с другими серверами посредством CXL в пределах одного дата-центра.

Software

Ниже — список основного ПО, которое потребуется для взаимодействия с CXL.

Системное администрирование:

• cxl — базовые команды CXL;
• daxctl — управление памятью для устройств с поддержкой DAX;
• dmesg — просмотр сообщений ядра;
• lspci — информация об устройствах PCI (требуется версия старше 3.0);
• lstopo — визуализация топологии системы.

Fabric Management:

• fm_cxl — инструменты и API для работы с CXL, специфичны для поставщиков и требуют патчей.

 Memory Tiering (уровневая память):

• numactl — инструмент управления NUMA.

Телеметрия:

• MemVerge Memory Viewer — анализатор работы памяти;
• perf — отладчик производительности.

Эмуляция:

• QEMU с функциями виртуализации устройств CXL.

Тестирование

Доставать образцы экспандеров нам было тяжело, поэтому как только они к нам попадали, мы сразу же приступали к тестированию.

В эксперименте участвовала серверная платформа с модулями DIMM Samsung 4800  DDR5  M321R4GA0BB0-CQKET. Конфигурация включала в себя восемь  модулей RAM объемом 32  ГБ на каждый и два CXL-экспандера по 256  ГБ. Таким образом, с помощью CXL-экспандеров к платформе добавлялось 512  ГБ оперативной памяти сверх штатного объема.

Тестирование предусматривало три итерации, использовались следующие инструменты:

• numactl — утилита командной строки Linux, которая позволяет контролировать политику NUMA (Non-Uniform Memory Access) для процессов и разделяемой памяти;
• Memory Latency Checker (MLC) от Intel — измеритель пропускной способности и задержек.

Выполнялось три теста:

1. RAM+CXL (использовалась вся память целиком: штатная и добавляемая экспандером).
2. RAM (использовалась только память на плате).
3. CXL (использовалась только память на экспандере).

MLC (memory latency checker)

Каждый из трех графиков выше представляет один из режимов тестирования. В данном тесте мы смотрим на задержки и пропускную способность, измеренную с помощью MLC Intel — график показывает ее зависимость от Delay Injection.

Тест синтетический и не предназначен для объективного суждения. Наша цель — определить, насколько медленнее работает память по CXL (PCIe) в сравнении с обычной.

На первый взгляд может показаться, что память, расположенная рядом с CPU (штатная память без CXL), значительно быстрее. Однако не все так просто. Ситуация меняется при учете задержки инъекции. При Delay Injection равной нулю мы действительно наблюдаем максимальную производительность. Однако серверные приложения, такие как базы данных, веб-серверы и другие, не могут работать с нулевой задержкой — из-за накладных расходов на обращение к кэшу CPU и RAM. В этом контексте мы не рассматриваем показатель возможной пропускной способности как объективный для приложений.

Данные из открытых источников [1, 2] показывают, что приблизительные значения задержки инъекции для PostgreSQL, MySQL и Nginx колеблются от 150 до 300  нс.

Картина становится интереснее. Получается, совместное использование RAM+CXL в режиме numactl --interleave демонстрирует пропускную способность, аналогичную штатной памяти, расположенной непосредственно у CPU. Осталось только удостовериться в правильности полученных результатов с помощью бенчмарков приложений.

Бенчмарки приложений

Для приложений PostgreSQL, MySQL и Nginx мы провели бенчмарки, алгоритмы которых разработали сами. Результаты объединили и получили общую картину, выраженную в процентном соотношении. Выходит, что совместная работа (CXL+RAM) отнимает примерно 2% производительности. Такой небольшой показатель вообще можно считать погрешностью. Использование исключительно CXL дает снижение быстродействия на 7% по сравнению со штатной памятью сервера.

Задержки в приложениях на примере PSQL

Немного подробнее рассмотрели, как отражается использование разной памяти на задержки при работе с БД.

Как и в предыдущем случае, при использовании CXL+RAM не наблюдается разница в задержках по сравнению с обращением только к штатной памяти. Нагрузка на БД была максимально высокой — с задействованием huge_page и других настроек производительности, о которых я рассказывал в статье про тестирование БД.

График также показывает, что при использовании исключительно CXL средние задержки на один запрос начинают расти с увеличением числа потоков. В дальнейшем мы подробнее изучим эту зависимость, а пока зафиксируем полученные результаты.

Продолжаем тестировать дальше

Мы продолжаем активно тестировать CXL. Следующим этапом планируем провести аналогичный эксперимент, но уже с памятью, расположенной на другом удаленном сервере. Тщательно измерим все показатели. Пока не видится никаких препятствий для интеграции этой технологии в нашу инфраструктуру.

Пример того, как расширители выглядят в реальности, — перед вами:

Итоги

Результаты первичных тестов нас устраивают. Мы активно продолжаем изучение технологии и проверку ее на реальных кейсах. Данные экспандеры скоро можно будет взять в тест у нас в Selectel-LAB. Следите за обновлениями!

Уже сейчас можно увеличивать предельно допустимый объем памяти в рамках одного выделенного сервера. На очереди — исследование Memory Poling для внешних серверов. Но это уже другая история.