Рост производительности вычислительных систем должен быть оплачен ростом энергопотребления, ведь каноны Power Management, основанные на законах физики, изменить нельзя. Вместе с тем, ничто не мешает оптимизировать их имплементацию с учетом архитектуры шины PCI Express. Функциональность Latency Tolerance Reporting является одним из инструментов решения такой задачи.
Цель публикации
Не дублируя теоретические сведения, изложенные в "Device Guidelines for PCI Express Technology Extensions", опишем небольшой лабораторный практикум, позволяющий оценить готовность персональных платформ и системного программного обеспечения к использованию данной технологии.
Определение LTR в спецификации PCI Express
Структура LTR Capability опционально включается в состав регистровых блоков периферийных контроллеров. Ее инициализация входит в обязанности системного программного обеспечения.

На основании информации об аппаратных особенностях устройства и условиях его функционирования в контексте платформы, драйвер инициализирует ряд регистров. В них указываются ограничения интервалов, связанных с обслуживанием запросов на чтение и запись. Таким образом, LTR устанавливает лимит времени, в течение которого устройство, выполняющее транзакцию на шине (инициатор), ожидает, что адресат транзакции (исполнитель), подтвердит ответ.

Периферийные контроллеры взаимодействуют с оперативной памятью платформы как Bus Master устройства, поэтому в типовом случае инициатором транзакции является некий интерфейсный контроллер (например NVMe, LAN или USB), а исполнителем — подсистема DRAM.
Latency Scale [2:0] 000 001 010 011 100 101 110...111 |
Value times 1 нс 32 нс 1024 нс 32768 нс 1048756 нс 33554432 нс не используется |
Превышение согласованных лимитов интерпретируется как аппаратная ошибка, а поддержание устройства в состоянии «постоянной готовности», повышает энергопотребление. Выход — адаптивное динамическое управление. Для периодического изменения правил обмена по шине, протоколом PCI Express предусмотрены специальные сообщения (LTR messages), несущие информацию о допустимых таймингах операций.
LTR Capability и виды трафика
Важной особенностью форматирования регистровых полей LTR Capability является дифференцирование ограничений латентности для snoop и non-snoop трафика. Рассмотрим этот вопрос подробно. Во всех системах, использующих кэш-память, актуальна проблема когерентности.
- Если Bus Master устройство выполняет чтение области оперативной памяти, более свежая копия которой находится в процессорной кэш-памяти, то устройством будут прочитаны устаревшие данные.
- Если Bus Master устройство выполнило запись области памяти, кэшированной копией которой располагает центральный процессор, то при последующем чтении этой информации процессор получит устаревшие данные из собственной кэш-памяти.
Ситуация (2) может возникнуть в любой кэшированной системе. Ситуация (1) может иметь место только для кэш-памяти с отложенной записью (write back). Для предотвращения обоих рассмотренных сценариев, процессор и системная логика отслеживают адреса обращений к памяти, такой мониторинг назван термином snoop. Тем же термином обозначается шинный трафик, для которого когерентность кэш-памяти гарантируется аппаратно.

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

Логично предположить, что snoop транзакция, требующая больше действий может выполняться дольше, чем non-snoop. Вероятно поэтому при разработке формата полей LTR структуры было принято решение о раздельном управлении таймингом для двух видов транзакций.
Пример 1. Контроллер USB3 xHCI
Исследуем платформу MSI x370 Xpower Gaming Titanium, в частности один из ее контроллеров USB3 xHCI, совместного авторства AMD и ASMedia.

Устройство декларирует наличие LTR. Если вы дочитали до этого места, то скорее всего сможете перевести в двоичный код и пользуясь Рис.1 расшифровать первые 4 байта (18h, 00h, 01h, 40h), идентифицирующие структуру, ее версию и указатель на следующую структуру в связанном списке.

Увы, следующие 4 байта, которые должны содержать два 16-битных слова, задающие ограничения латентности, нулевые. Вероятно, системное программное обеспечение не инициализировало LTR.
Пример 2. Контроллер LAN
Исследуем платформу ASUS Prime B360-Plus, а точнее — ее интегрированный LAN-контроллер разработки Realtek.

Устройство декларирует наличие LTR. Первые 4 байта (18h, 00h, 81h, 17h), согласно Рис.1 идентифицируют структуру LTR (ID=0018h), версию 1, указатель на следующую структуру (178h) в связанном списке.

Следующие 4 байта содержат два 16-битных слова, отражающих установленные ограничения латентности. Несмотря на приведенные выше теоретические соображения, значения латентности для non-snoop и snoop трафика совпадают: оба слова равны 1003h. Подчеркнем, такое совпадение является частным случаем, в общем случае латентность для двух видов трафика может быть различной, иначе нет смысла в применении двух регистров
Согласно Рис.2 расшифруем значение латентности:
1003h = 0001.0000.0000.0011b (биты 15-00)
- Биты [12-10] = 100b, единица измерения в 1048576 наносекунду, чуть более одной миллисекунды;
- Биты [9-0] = 003h, это множитель.
Таким образом, получаем величину около трех миллисекунд.
Резюме
Чтобы технология LTR функционировала, экономя в зависимости от контекста наносекунды или ватты, перед системными программистами, в частности — разработчикам драйверов и UEFI, стоят сложные, но вполне осуществимые задачи.
Примечание
С целью соблюдения требований законодательства, мы отказались от публикации иллюстраций из спецификации PCI Express. Все описания форматов регистровых полей взяты из открытых источников.
Сохранение двоичного дампа конфигурационного PCI-пространства выполнено с помощью утилиты RWEverything. Для получения текстовых рапортов на основании двоичных дампов использовано Java-приложение собственной разработки. Краткая инструкция со скрин-шотами здесь. Альтернативные сценарии исследования PCI/PCIe устройств изложены в статье «Пособие для компьютерных диггеров».