Диагностика памяти CXL в системах AMD и ASUS

Одно-сокетный сервер с 1.2 ТБ оперативной памяти — звучит как опечатка в спецификации. Но если перед вами ASUS RS520QA-E13-RS8U с процессором AMD EPYC 9755 и четырьмя модулями Montage CXL Type 3, это ровно то, что покажет команда free -mh. Двенадцать штатных DIMM-слотов плюс восемь через CXL-контроллеры — и вот у вас 20 планок DDR5 на одном сокете. Штатные каналы работают на скорости 1DPC (до DDR5-6400), CXL-модули подключены через PCIe 5.0 и добавляют ёмкость, не снижая частоту основной памяти. Подробнее о том, чем серверная DDR5 отличается от десктопной и какие типы модулей применяются в современных платформах, — в материале об особенностях и типах серверной оперативной памяти.

Но за гигабайтами стоят латентности, NUMA-топология, RAS-метрики и вопрос «а оно вообще нормально работает?». Разберёмся, как диагностировать CXL-память от BIOS до продакшн-мониторинга.

Что видит процессор: BIOS и настройка CXL

Прежде чем Linux увидит CXL-устройства, их нужно корректно активировать на уровне UEFI. В серверах ASUS на платформе AMD EPYC 9004 (Genoa) и 9005 (Turin) настройки CXL спрятаны в разделе AMD CBS (Common BIOS Settings). Путь выглядит примерно так: Advanced → AMD CBS → DF Configuration → Memory Addressing.

Здесь нас интересуют три вещи. Первая — включение CXL SPM (System Physical Memory). Этот параметр определяет, будет ли CXL-память отображаться как системная RAM или останется в режиме DAX-устройства. Вторая — настройка bifurcation для PCIe-слотов. CXL-контроллеры Montage используют x8-линки, поэтому для четырёх контроллеров нужно разделить x16-слоты в режим x8/x8. Некоторые конфигурации допускают bifurcation до x4, но для CXL Type 3 это редкий сценарий. Третья — обход ограничений 2DPC. В плотных системах вроде 2U4N физически невозможно разместить 24 DIMM-слота на половину ширины юнита, и CXL-расширение решает эту проблему архитектурно: 12 слотов остаются в режиме 1DPC с полной скоростью, а дополнительная ёмкость приходит через PCIe.

Отдельный нюанс — порядок инициализации. AMD EPYC 9005 поддерживает CXL 2.0, и CXL-устройства обнаруживаются на этапе POST. Если в BMC (ASUS ASMB12-iKVM) отображается корректное количество памяти, включая CXL-модули, — BIOS отработал штатно. Когда что-то пошло не так, BMC покажет POST-код ошибки прямо на дисплее материнской платы — ASUS предусмотрительно не убрали его даже в сверхплотном 2U4N дизайне.

Ещё один момент, который часто упускают: версия AGESA (AMD Generic Encapsulated Software Architecture) в прошивке. Если CXL-модули не определяются после корректной настройки bifurcation — обновите BIOS до последней версии с сайта ASUS. Разница между версиями прошивки бывает критичной.

Обнаружение и NUMA-топология в Linux

После загрузки ОС первая проверка — убедиться, что ядро видит CXL-устройства. Ядро Linux поддерживает CXL начиная с версии 5.12, но для полноценной работы с Type 3 рекомендуется 6.1+. Проверка cxl памяти начинается с утилиты lspci: фильтруем по ключевому слову CXL и смотрим, сколько устройств обнаружено. На системе с четырьмя контроллерами Montage вы увидите четыре строки. Если передать lspci флаг расширенной детализации (-vv) и адрес конкретного устройства, утилита покажет тип устройства, поддерживаемые CXL-протоколы (CXL.mem для Type 3), а также параметры PCIe-линка — ширину и скорость.

Дальше — NUMA-топология. CXL-память отображается как отдельный NUMA-узел без привязанных CPU-ядер. Это фундаментальное отличие от штатной DRAM. Утилита numactl с флагом --hardware выведет полную картину: количество узлов, объём памяти в каждом, привязку ядер и — что ценно — матрицу расстояний между узлами.

На одно-сокетной системе с CXL вы увидите два NUMA-узла: node 0 со всеми ядрами и 768 ГБ (12 × 64 ГБ), и node 1 без ядер с 512 ГБ (8 × 64 ГБ CXL). Мониторинг памяти linux через numactl покажет и матрицу расстояний — числа в ней отражают относительную латентность между узлами. Типичное значение для CXL-узла — в 1.7–2 раза выше, чем для локальной DRAM. Матрица с node distances 10 для локального узла и 17–20 для CXL — признак корректной настройки.

Для визуализации топологии пригодится lstopo из пакета hwloc — она генерирует графическую карту системы, где видны CPU-ядра, кэши, DRAM-каналы и CXL-устройства с их связью через PCIe.

Ещё один полезный инструмент — cxl-cli, который ставится вместе с пакетом ndctl. Команда cxl list с флагами для отображения memdev-устройств и human-readable формата покажет размер каждого CXL-устройства, его адресное пространство и режим работы (ram или devdax). Это быстрый способ проверить, что все модули определились корректно и доступны ядру.

Латентность и пропускная способность: честные цифры

CXL Type 3 — это не замена DRAM, а её расширение. Между контроллером CXL и процессором стоит PCIe 5.0-линк, и он добавляет задержку. Разница в латентности между локальной DDR5 и CXL-памятью составляет примерно 70 нс — это цена за прохождение через CXL-контроллер и PCIe-мост.

Для измерения разницы на вашей системе есть несколько инструментов:

Для сравнения CXL-памяти с локальной DRAM бенчмарки запускаются через numactl с привязкой аллокаций к конкретному NUMA-узлу. STREAM, к примеру, запускается с указанием выделять память на CXL-узле (node 1), а потоки исполнения — на ядрах основного узла (node 0). Разница в результатах Triad между двумя узлами покажет реальный штраф CXL на вашем конкретном железе.

stressapptest — отдельная история. Он не просто гоняет паттерны, а целенаправленно ищет битовые ошибки, проблемы с таймингами и некорректное поведение контроллера под нагрузкой. Запускается с привязкой к CXL-узлу, с указанием объёма памяти и длительности. Часовой прогон на полном объёме — разумный минимум перед вводом в эксплуатацию.

Micron CXL Memory Resource Kit (CMRK) включает модифицированные версии STREAM и multichase с CXL-специфичными опциями. Репозиторий на GitHub — cxl-micron-reskit — содержит готовые скрипты для автоматизации тестов.

RAS: ошибки, инжекция и мониторинг здоровья

Reliability, Availability, Serviceability — три буквы, без которых CXL-память не выйдет в продакшн. Диагностика здесь строится на трёх уровнях: мониторинг ошибок, инжекция для валидации и firmware-тесты.

Мониторинг ошибок памяти в Linux строится вокруг демона rasdaemon. После установки и запуска он работает в фоне, собирает Hardware Events через kernel tracing и складывает их в SQLite-базу. Просмотр накопленных ошибок — через утилиту ras-mc-ctl. Для CXL-устройств rasdaemon отлавливает как корректируемые (CE), так и некорректируемые (UE) ошибки с привязкой к конкретному устройству и адресу. Накопление CE в одном адресном диапазоне — сигнал к замене модуля ещё до того, как ошибка станет фатальной.

Инжекция ошибок — обязательный этап валидации перед продакшном. Два основных инструмента:

AMD RAS Tool с Linux EINJ (Error Injection Interface) — позволяет инжектировать ошибки на уровне CXL.io и CXL.mem. Ядро должно быть собрано с CONFIG_ACPI_APEI_EINJ=y. Через sysfs-интерфейс /sys/kernel/debug/apei/einj/ задаётся тип ошибки и адрес в CXL-пространстве.

Micron MXCLI — утилита командной строки для CXL mailbox-команд. Через vendor-specific (VS) команды она инжектирует ошибки непосредственно в контроллер CXL-модуля. Помимо инжекции, MXCLI читает health-информацию, логи событий, позволяет обновлять firmware и мониторить счётчики производительности. Последние релизы добавили поддержку команд CXL 3.1 и landing page для быстрой проверки состояния модуля. Запускается с правами суперпользователя в двух режимах: интерактивный (с автообнаружением устройств, меню и автодополнением) и командная строка с JSON-ответами для интеграции со скриптами и системами мониторинга типа Zabbix или Prometheus.

Micron также выпустила GUI-приложение mxdiagnostic — оно подключается к серверу локально или удалённо, визуализирует NUMA-топологию и показывает PCIe eye diagram. Для тех, кто предпочитает графику, — альтернатива CLI.

Для изоляции неисправной CXL-памяти ядро Linux поддерживает механизм memory poisoning — отмеченные страницы исключаются из аллокации. В сочетании с firmware-first error handling (AMD передаёт обработку первичных ошибок прошивке AGESA), цепочка выглядит так: контроллер CXL → прошивка AGESA → APEI/GHES → ядро Linux → rasdaemon → алерт администратору.

Режимы работы: System RAM, DAX и переключение

CXL-память в Linux может работать в двух режимах, и выбор между ними зависит от задачи.

System RAM — память добавляется в общий пул, ядро может использовать её для любых аллокаций. С включённым memory tiering (kernel 6.1+) горячие страницы мигрируют в локальную DRAM, холодные — в CXL. Этот режим подходит для задач с большим объёмом данных, но неравномерным доступом: in-memory базы, EDA-симуляции, виртуализация.

DAX (devdax) — память доступна как устройство /dev/dax0.0, приложение работает с ней напрямую через mmap(). Подходит для приложений, которые сами управляют размещением данных: Redis с модулем CXL, SAP HANA, custom-аллокаторы.

Переключение между режимами выполняется утилитой daxctl: команда reconfigure-device с указанием целевого режима (system-ram или devdax) и идентификатора устройства. Операция требует, чтобы память не использовалась — для обратного перевода из system-ram в devdax нужно предварительно перевести узел в offline. В BIOS ASUS параметр CXL SPM с опцией offline позволяет настроить автоматический режим для high-availability сценариев — если CXL-модуль деградирует, система продолжает работать на локальной DRAM.

Текущий режим каждого CXL-устройства проверяется через daxctl list. Если вы переключили память в system-ram, она появится в стандартных утилитах мониторинга (free, numactl) как обычный NUMA-узел. При возврате в devdax — исчезнет из системной статистики, но останется доступной напрямую через файл устройства /dev/dax0.0.

Ядро 6.1+ с включённым автоматическим tiering (NUMA balancing) умеет мигрировать страницы между DRAM и CXL-памятью прозрачно для приложений. Статистику миграций можно отслеживать через sysctl-параметры NUMA и счётчики в /proc/vmstat — по ним видно, сколько страниц мигрировало между узлами и в каком направлении.

Оптимизация и балансировка нагрузки

Мониторинг памяти linux в системах с CXL — это постоянный процесс, а не разовая проверка cxl памяти после установки. Привязка критичных процессов к DRAM, а фоновых — к CXL, настраивается через numactl или cgroups v2. Numactl предлагает два режима привязки. Жёсткая (--membind) запрещает аллокацию за пределами указанного узла — если память закончится, процесс получит OOM. Мягкая (--preferred) действует как рекомендация: ядро постарается разместить данные на выбранном узле, но при нехватке откатится на другой. Для latency-critical приложений — жёсткая привязка к DRAM, для batch-обработки — мягкая к CXL.

На платформе AMD EPYC 9005 с CXL-расширением серверы вроде ASUS RS520QA достигают 1.2+ ТБ памяти на сокет. Для AI-инференса и HPC-задач это означает, что модели, которые раньше требовали распределённой памяти на нескольких узлах, помещаются в один сервер. О том, как выбрать и собрать сервер для ИИ под конкретные задачи инференса и обучения, — отдельный разбор. А cxl type 3 устройства от Montage с контроллерами на два DIMM-слота каждый дают гибкость в наращивании — можно начать с одного модуля и добавлять по мере роста нагрузки.

Телеметрия через BMC (ASUS ASMB12-iKVM) дополняет картину: температуры CXL-модулей, статусы линков, счётчики ошибок — всё это доступно через IPMI и веб-интерфейс BMC без необходимости заходить в ОС.

Что дальше: CXL-пулы и масштабирование

Настройка bios asus для CXL сегодня — это per-node конфигурация: каждый сокет видит свои CXL-устройства. Но спецификации CXL 3.0/3.1 описывают shared memory и dynamic capacity devices (DCD), где пул памяти разделяется между несколькими хостами через CXL-свитчи. AMD EPYC с 64 CXL-совместимыми линиями и поддержкой bifurcation до x4 готов к этим сценариям на уровне железа.

Для оркестраторов (Kubernetes, Proxmox) CXL-память пока воспринимается как обычный NUMA-узел — никаких специальных плагинов не требуется. Привязка подов к CXL-памяти через topology manager в Kubernetes работает стандартным образом. Для Proxmox — NUMA-настройки виртуальных машин позволяют задать, какие узлы доступны конкретной VM, и тем самым изолировать CXL-память для некритичных задач.

Экономика тоже интересная. DDR5 96 ГБ модули через CXL обходятся дешевле, чем 256 ГБ RDIMM в штатных слотах. Один сервер с 1.2 ТБ заменяет кластер из нескольких узлов для memory-bound задач: меньше лицензий, меньше сетевого трафика, меньше латентности на межузловое взаимодействие.

CXL-память уже не экспериментальная технология. Это серийные модули в серийных серверах с ядром Linux, которое знает, что с ними делать. Спецификация CXL 4.0 удваивает пропускную способность до 128 GT/s и расширяет RAS-функциональность — а значит, инструменты диагностики, описанные здесь, станут фундаментом для работы с CXL следующего поколения. Вопрос не «стоит ли», а «для каких задач» — и ответ зависит от вашего профиля латентности.