Intel Platform Monitoring Technology (PMT) - это стандартный механизм телеметрии платформы, введённый Intel начиная с процессоров Sapphire Rapids и графических ускорителей Intel Xe. В отличие от традиционных счётчиков производительности (perf/PMU), PMT предоставляет блочную телеметрию: агрегированные счётчики энергопотребления, тепловой активности, частот и использования функциональных блоков, которые формируются аппаратурой и прошивкой. Такой подход позволяет мониторить состояние платформы с минимальными накладными расходами и без точного знания внутренностей конкретного чипа.
Разберём архитектуру PMT, драйверы в ядре Linux, доступ к телеметрии через sysfs, взаимодействие с существующими механизмами мониторинга и практическое применение в дата-центре.
Что такое PMT и зачем она нужна
Традиционный мониторинг производительности в Linux опирается на PMU (Performance Monitoring Unit): точные счётчики событий (инструкции, кэш-промахи, промахи TLB), доступные через perf. PMU эффективен для профилирования конкретных процессов, но имеет ограничения: число счётчиков ограничено, настройка требует знания событийных кодов для каждого поколения процессора, а совокупные показатели (энергопотребление всего домена, тепловое состояние) собираются через разрозненные интерфейсы (RAPL, thermal zones, IPMI).
PMT решает эти проблемы иначе: прошивка платформы агрегирует телеметрию в блоках (telemetry regions), а драйвер лишь экспортирует их в пользовательское пространство. Приложение читает готовые бинарные блоки и интерпретирует их по таблице смещений, поставляемой вместе с платформой. Такой подход даёт три преимущества: минимальные накладные расходы (одно чтение MMIO вместо десятков MSR), независимость от поколения процессора (таблица описывает содержимое блока), покрытие показателей, недоступных через PMU (энергия по доменам, состояние термических сенсоров, активность памяти и ускорителей).
Для администратора это означает переход от ручного сбора разрозненных показателей к чтению стандартизированных блоков: вместо скриптов, объединяющих чтения MSR, thermal zones и IPMI, используется единый источник данных с гарантированной согласованностью значений внутри блока. Согласованность важна: энергия и температура, снятые в разное время, могут относиться к разным режимам работы узла и искажать картину при анализе.
Архитектура PMT в ядре Linux
В ядре Linux PMT реализован через драйверы intel_vsec (Virtual Security Exchange - обнаружение блоков PMT на PCI) и intel_pmt (экспорт телеметрии). Драйвер intel_vsec сканирует PCI-конфигурационное пространство устройств, находит capabilities с идентификаторами PMT (VSEC ID 0x02 и выше), и регистрирует обнаруженные блоки: телеметрию, crashlog, watchpoints.
Драйвер intel_pmt_telemetry создаёт устройства-символьные файлы и sysfs-записи для каждого телеметрического региона. Приложение (или демон мониторинга) читает регион через mmap или read и декодирует значения по таблице (GUID-идентификатор определяет формат блока).
Основные компоненты:
- intel_vsec - обнаружение PMT-блоков на PCI-устройствах (процессоры Sapphire Rapids, Granite Rapids; GPU Intel Xe; чипсеты).
- intel_pmt_telemetry - экспорт телеметрических регионов в sysfs и через устройство /dev/pmt.
- intel_pmt_crashlog - экспорт журналов сбоев (crashlog) для отладки после сбоев.
- intel_pmt_watchpoint - настройка точек наблюдения за адресами памяти в оборудовании.
Каждый блок описывается GUID (глобальный идентификатор формата): одна платформа может предоставлять несколько блоков с разными наборами показателей (энергия, температура, частоты, память). Обновления прошивки могут добавлять новые поля в конец блока, сохраняя обратную совместимость по смещениям.
Доступ к телеметрии через sysfs
После загрузки драйверов телеметрические регионы появляются в sysfs:
ls /sys/class/intel_pmt/telemetry*/Каждый регион содержит файлы guid (идентификатор формата), size (размер блока) и доступ к данным через символическое устройство. Чтение блока:
cat /sys/class/intel_pmt/telemetry/telem0/dataДанные бинарные: набор 32-битных и 64-битных значений на фиксированных смещениях. Для Sapphire Rapids документированы блоки с энергией (energy by domain), температурой (temperature by sensor), частотами (frequency by core), активностью памяти (memory bandwidth). Утилита turbostat последних версий частично использует PMT-блоки, выводя агрегированные показатели без ручного декодирования.
Типичный декодер в пользовательском приложении выглядит так: читается весь блок (несколько килобайт), затем по таблице смещений извлекаются нужные поля, масштабируются (например, энергия в микроджоулях делится на интервал между чтениями для получения мощности) и передаются в систему мониторинга. Формат блока стабилен внутри одной платформы, поэтому декодер пишется один раз.
Взаимодействие с RAPL, thermal и perf
PMT дополняет существующие механизмы, а не заменяет их. RAPL (Running Average Power Limit) через MSR даёт энергию по доменам (package, core, DRAM) с точностью до домена, но требует чтения MSR для каждого домена; PMT-блок энергии собирает все домены одним чтением. Thermal zones ядра предоставляют температуры через sysfs, но набор датчиков и их обозначение меняются между платформами; PMT даёт единый блок со всеми сенсорами.
perf остаётся основным инструментом профилирования приложений: точные события на уровне ядра и процесса не имеет смысла агрегировать в платформенную телеметрию. Разумное разделение: perf для отладки конкретных процессов, PMT для постоянного мониторинга платформы, RAPL для управления лимитами энергопотребления (через powercap), IPMI/BMC для внеполосного мониторинга при выключенной ОС.
На практике связка выглядит так: демон раз в секунду читает PMT-блоки (энергия, температуры, частоты) и публикует в Prometheus; управление лимитами выполняется через powercap/RAPL; при подозрении на проблему конкретного процесса запускается perf; при сбое узла crashlog выгружается для анализа. Для GPU-узлов аналогичную роль играют блоки телеметрии Xe: использование шейдерных блоков, температура чипа, потребление и такты памяти доступны тем же механизмом через ту же утилиту чтения блоков, что унифицирует мониторинг процессорных и графических узлов в одной инфраструктуре.
Отдельного внимания заслуживает гранулярность чтения: телеметрический блок обновляется прошивкой с фиксированным интервалом (порядка 10-100 мс), поэтому чтение чаще этого интервала даёт одинаковые значения. Демон мониторинга должен учитывать период обновления: чтение раз в секунду оптимально, а попытка собирать данные с частотой выше 10 Гц не даст новой информации и лишь увеличит накладные расходы на syscall.
Практический порядок настройки мониторинга PMT
- убедиться, что процессор/платформа поддерживает PMT (Sapphire Rapids и новее для серверов, Xe для GPU);
- загрузить модули ядра intel_vsec и intel_pmt (в новых ядрах собираются автоматически);
- проверить обнаружение блоков через
ls /sys/class/intel_pmt/иdmesg | grep vsec; - определить GUID-идентификаторы доступных блоков и найти описание формата в документации платформы;
- настроить демон мониторинга (Prometheus-экспортер или собственный скрипт) на периодическое чтение блоков;
- настроить алерты на критические показатели (температура, энергопотребление, ошибки).
Типичные проблемы: отсутствие блоков при выключенной поддержке в BIOS (проверить опцию Platform Monitoring Technology), разные GUID на разных поколениях процессоров (таблица смещений меняется), блокировка чтения при отсутствии прав (udev-правила для доступа не-root пользователей), пустые значения при неактивированной прошивке телеметрии (некоторые OEM отключают блоки в своём firmware).
Диагностика проблем выполняется в такой последовательности: проверить загрузку модулей (lsmod | grep -E 'intel_(vsec|pmt)'), убедиться в обнаружении устройств (dmesg | grep -i vsec показывает найденные capabilities с адресами), сверить количество блоков с документацией платформы. Если блоки не обнаруживаются на поддерживаемом процессоре, следует проверить версии BIOS и прошивки BMC: телеметрия может требовать актуальной прошивки, а OEM-образы иногда откатывают поддержку. Для GPU Intel Xe аналогичные блоки появляются после загрузки драйвера i915/xe, и их отсутствие обычно связано с версией прошивки карточки.
Для интеграции в существующую инфраструктуру мониторинга достаточно написать небольшой экспортер: программа читает блоки по фиксированным смещениям, переводит значения в метрики Prometheus (счётчик энергии, датчики температур, частоты) и публикует на HTTP-эндпоинте. Поскольку блок небольшой и чтение дешёвое, один экспортер обслуживает все блоки узла с накладными расходами менее 0.1 процента ядра.
Применение в дата-центре и ограничения
Основной сценарий PMT в дата-центре - мониторинг энергопотребления и теплового состояния узлов кластера. Регулярное чтение телеметрических блоков (раз в секунду или реже) даёт полную картину без нагрузки на CPU: чтение одного MMIO-блока занимает микросекунды, тогда как опрос десятков датчиков через MSR или IPMI на порядок дороже. Это позволяет собирать телеметрию со всех узлов кластера в реальном времени без влияния на рабочие нагрузки. Приложения, чувствительные к энергопотреблению (например, HPC с лимитами на стойку), получают точные данные для планирования лимитов и раскладки задач по узлам.
Второй сценарий - отладка после сбоев: crashlog сохраняет состояние регистров и памяти при падении, а драйвер экспортирует журнал после перезагрузки, что упрощает расследование без дополнительного оборудования. Журнал содержит состояние функциональных блоков, последних транзакций и термических событий, что позволяет локализовать причину сбоя без воспроизведения проблемы. Третий сценарий - валидация теплового дизайна: мониторинг температур и энергопотребления под тестовой нагрузкой подтверждает соответствие охлаждения спецификации. Четвёртый сценарий - балансировка нагрузки по тепловому признаку: планировщик кластера учитывает температуру и энергопотребление узлов при размещении задач, перенося нагрузку с перегретых узлов.
Ограничения технологии: формат блоков зависит от платформы (нет универсального декодера), документация доступна ограниченно (требуется NDA для некоторых блоков), PMT не заменяет perf для профилирования приложений (блочная телеметрия агрегирована и не привязана к процессам), а поддержка в open-source инструментах ограничена turbostat и несколькими экспортерами. Также телеметрия идёт через прошивку с задержкой обновления (обычно раз в 10-100 мс), поэтому мгновенные пики короче этого интервала не отражаются в блоках.
Несмотря на ограничения, вектор развития однозначен: вендоры движутся к платформенной блочной телеметрии, поскольку точечные счётчики плохо масштабируются на сотни узлов с тысячами датчиков. Появление похожих механизмов у других вендоров (AMD SB-RMI, Arm MPAM-телеметрия) говорит о формировании отрасли стандартов платформенного мониторинга, и инструменты, построенные вокруг PMT сегодня, с минимальными изменениями переносятся на будущие платформы.
Заключение по мониторингу платформы Intel
Intel Platform Monitoring Technology - эволюция телеметрии платформы: вместо разрозненных интерфейсов (MSR, IPMI, thermal zones) предоставляется стандартизированный блочный доступ к агрегированным показателям. В Linux поддержка реализована через intel_vsec/intel_pmt и доступна на процессорах Sapphire Rapids и новее. Для дата-центров PMT открывает эффективный мониторинг энергопотребления и теплового состояния всего кластера в реальном времени, а crashlog упрощает отладку после сбоев. При этом технология не заменяет perf для профилирования приложений, а дополняет её данными платформенного уровня, формируя полную картину состояния системы от процессов до охлаждения.