Поделиться через

Отслеживание грязных битов

В этой статье описывается функция отслеживания грязных битов, которая поддерживается начиная с Windows 11 версии 24H2 (WDDM 3.2). Драйверы, поддерживающие динамическую миграцию на устройствах параллелизации GPU , также должны поддерживать отслеживание грязных битов.

Введение

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

Передача содержимого памяти между физическими узлами выполняется в двух общих проходах:

  1. Браунаут: В течение периода браунаута виртуальная машина по-прежнему работает, но система совершает итеративное сохранение всех измененных данных. Цель заключается в том, что объем данных, грязных во время каждой итерации, становится меньше, пока он не будет конвергентирован на меньшем подмножестве данных, которые можно быстро копировать. Этот объем данных зависит от рабочей нагрузки компьютера и не гарантировано, что он сведется к определённому размеру.

  2. Отключение. В течение периода отключения виртуальная машина приостановлена, и все оставшиеся грязные данные копируются. Эта копия гарантирует, что полученные данные на конечном компьютере совпадают с состоянием источника.

Без отслеживания грязных битов система должна полагаться на одну полную копию буфера кадров GPU (VRAM) в течение периода отключения. Чтобы поддерживать brownout операцию, оборудование должно иметь возможность активно отслеживать изменённые страницы памяти и сообщать об этом ОС, чтобы ОС точно знала, какую именно память копировать.

Подробный дизайн

Возможности создания отчетов

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

Запуск и остановка «грязного захвата»

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

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

Запрос грязных битов

Грязная информация представлена в виде битплана грязных страниц. Каждый бит в битовой плоскости представляет одну "страницу" памяти. Размер страницы грязных данных не должен соответствовать естественным размерам страниц виртуальной адресации на GPU (например, 4 КБ/64 КБ). Это может быть наиболее подходящим для конкретного оборудования. Драйвер сообщает этот размер страницы во время инициализации.

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

Виртуальные машины не обязательно переносятся в одно место назначения, поэтому миграция буфера кадров происходит для каждого виртуального экземпляра GPU. Поэтому драйвер должен иметь возможность запрашивать сведения о битовом плане для указанного под диапазона общего буфера кадров, представляющего этот конкретный виртуальный экземпляр GPU. Например, 8-гигабайтная GPU, разделенная на четыре части, должна иметь возможность отдельно запрашивать и сбрасывать биты битового плана для каждого из диапазонов в 2 ГБ VRAM, не затрагивая данные грязных битов других частей.

Изменения DDI

Возможности

В DXGK_QUERYADAPTERINFOTYPE добавляются следующие ограничения.

  • DXGKQAITYPE_DIRTYBITTRACKINGCAPS

    Теперь система вызывает функцию DXGkDDdiQueryAdapterInfo с DXGK_QUERYADAPTERINFOTYPE типа DXGKQAITYPE_DIRTYBITTRACKINGCAPS во время инициализации адаптера, чтобы определить возможности драйвера и оборудования для отслеживания грязных битов.

    KMD должен заполнить указанную DXGK_DIRTY_BIT_TRACKING_CAPS структуру, на которую указывает pOutputData .

  • DXGKQAITYPE_DIRTYBITTRACKINGSEGMENTCAPS

    Если KMD установил DirtyBitTrackingSupported в значение TRUE, система вызывает функцию DxgkDdiQueryAdapterInfo с параметром DXGK_QUERYADAPTERINFOTYPE, равным DXGKQAITYPE_DIRTYBITTRACKINGSEGMENTCAPS, для каждого сегмента памяти в системе для запроса сведений о поддержке отслеживания грязных битов.

    KMD должен заполнить указанную DXGK_DIRTY_BIT_TRACKING_SEGMENT_CAPS структуру, на которую указывает pOutputData .

DDI, основанные на памяти

Отслеживание операций изменения в VRAM предназначено для выделений, которые могут не поддерживаться непрерывно. Первоначальное использование в Динамической миграции, например, применяется к отслеживанию резерва framebuffer для виртуальной функции. Таким образом, физические адреса, представленные в отслеживании грязных битов, состоят из коллекции диапазонов, представляющих распределение, на которое выполняется работа.

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

  • Last updated on