Latency Tolerance Reporting в контексте PCI Express

Рост производительности вы­чис­ли­тель­ных сис­тем дол­жен быть оп­ла­чен рос­том энер­го­по­треб­ле­ния, ведь ка­но­ны Po­wer Ma­na­ge­ment, ос­но­ван­ные на за­ко­нах фи­зи­ки, из­ме­нить нель­зя. Вмес­те с тем, ни­что не ме­ша­ет оп­ти­ми­зи­ро­вать их им­пле­мен­та­цию с уче­том ар­хи­тек­ту­ры ши­ны PCI Ex­press. Фун­к­ци­о­наль­ность La­ten­cy To­le­rance Re­port­ing яв­ля­ет­ся од­ним из ин­ст­ру­мен­тов ре­ше­ния та­кой за­да­чи.

Цель публикации

Не дублируя теоретические сведения, изложенные в "Device Guidelines for PCI Express Tech­no­lo­gy Ex­ten­sions", опишем небольшой лабораторный практикум, позволяющий оценить го­тов­ность ­пер­со­наль­ных плат­форм и сис­тем­но­го про­грам­мно­го обес­пе­че­ния к ис­поль­зо­ва­нию дан­ной тех­но­ло­гии.

Определение 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 трафика. Рассмотрим этот вопрос подробно. Во всех системах, использующих кэш-память, актуальна проблема когерентности.

1. Если Bus Master устройство выполняет чтение области оперативной памяти, более свежая копия которой на­хо­дит­ся в про­цес­сор­ной кэш-памяти, то устройством будут прочитаны устаревшие данные.
2. Если 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 устройств из­ло­же­ны в статье «Пособие для компьютерных диггеров».