Intel выносит на обсуждение технологию RAR based TLB shootdowns

Виртуальная память, ос­но­ван­ная на транс­ля­ции ли­нейно­го ад­ре­са в фи­зи­ческий, а так­же при­ме­не­ние TLB для ус­ко­ре­ния про­цес­са за­мет­но вли­я­ет на про­из­во­ди­тель­ность вы­чис­ли­тель­ных плат­форм. Со­пут­ст­ву­ю­щая за­да­ча — обес­пе­че­ние син­хро­ни­за­ции со­дер­жи­мо­го TLB меж­ду ло­ги­че­ски­ми CPU. Ины­ми сло­ва­ми, все вы­пол­ня­е­мые по­то­ки, от­но­ся­щи­е­ся к за­дан­но­му про­цес­су, дол­ж­ны оди­на­ко­вым об­ра­зом «ви­деть» его ад­рес­ное про­ст­ран­ст­во. Ак­се­ле­ра­цию этой за­да­чи при­зва­на обес­пе­чить тех­но­ло­гия Re­mote Ac­tion Re­quest bas­ed TLB shoot­downs. Не при­ни­мая во вни­ма­ние ус­то­яв­шу­ю­ся аб­бре­ви­а­ту­ру, ее на­зва­ние со­кра­ща­ют до RAR.

Постановка задачи

Запуская приложение, ОС создает для него вир­ту­аль­ное адресное пространство, подготавливая дескрипторы стра­ниц в та­б­ли­цах транс­ля­ции. Выделение и освобождение блоков памяти, плюс своппинг, требуют об­нов­ле­ния таблиц. Ко­гда ко­ли­че­ст­во об­ра­ба­ты­ва­е­мых потоков превышает количество логических про­цес­со­ров плат­фор­мы, мно­го­за­дач­ность вызывает пе­ри­о­ди­че­ское пе­ре­клю­че­ние контекста, уменьшая вре­мя жизни ин­фор­ма­ции в TLB.

Проблема заключается в том, что из­ме­не­ния со­дер­жи­мо­го таблиц в оперативной памяти не будут иметь си­лы, по­ка про­цес­сор использует устаревшие кэшированные копии дескрипторов из TLB. Для сброса или так на­зы­ва­е­мой ин­ва­ли­да­ции TLB существует множество методов, в частности, специальная инструкция INVLPG. Она позволяет очистить элемент TLB, отвечающий за отображение адреса, указанного в инструкции. Кроме то­го, при некоторых системных событиях, например, загрузке регистра управления CR3, содержащего ба­зо­вый адрес каталога страниц, TLB очи­ща­ет­ся ав­то­ма­ти­че­ски. Именно для этого применяется, казалось бы бес­смыс­лен­ная по­сле­до­ва­тель­ность команд, ко­то­рую ино­гда мож­но встретить в при­ви­ле­ги­ро­ван­ном коде ОС:

MOV EAX,CR3
MOV CR3,EAX

В результате содержимое CR3 не изменится, но блок TLB будет очищен.

В многоядерной системе, после того, как один из логических процессоров обновил таблицу страниц, ин­ва­ли­да­ция TLB дол­ж­на быть выполнена для всех логических процессоров, использующих в данный момент эту таб­ли­цу, каж­дый из ко­то­рых располагает собственным TLB. Именно эту процедуру призвана ускорить тех­но­ло­гия Remote Action Re­quest bas­ed TLB shoot­downs.

Программное решение

Для начала рассмотрим программное выполнение синхронизации TLB.

Последовательность операций при программной синхронизации TLB двух логических процессоров (для платформы, не поддерживающей RAR based TLB shootdowns)

Последовательность операций при программной синхронизации TLB двух логических процессоров
(для платформы, не поддерживающей RAR based TLB shootdowns)

Левый блок отражает действия процессора, инициирующего синхронизацию TLB, это — ILP (Initiator Logical Pro­ces­sor). Условно назовем его локальным. Правый блок отражает действия процессора или группы про­цес­со­ров, которым ад­ре­со­ва­на ко­ман­да син­хро­ни­за­ции TLB, это — RLP (Recipient Logical Processor). Ус­лов­но назо­вем его удаленным (Re­mote), хо­тя речь о событиях, происходящих в пределах одной плат­фор­мы.

Локальный процессор, выполнив обновление дескрипторов PTE (Page Table Entry), отправляет сообщение IPI (In­ter-Pro­ces­sor Inter­rupt) удаленному процессору. Не забываем и про очистку собственного TLB — Invalidate own TLB. Затем ло­каль­ный про­цес­сор ожидает завершения очистки TLB на всех удаленных процессорах — Poll memory for all RLP's to com­ple­te, о ко­то­ром они сообщают программной установкой соответствующих фла­гов в оперативной памяти.

Удаленный процессор, приняв запрос на прерывание в виде сообщения IPI, запускает процедуру обработки. Пе­ре­да­ча уп­рав­ле­ния с изменением уровня привилегий — Transition to Ring 0 — требует большого ко­ли­че­ст­ва раз­лич­ных про­ве­рок, со­хра­не­ния контекста прерываемой процедуры и загрузки контекста про­це­ду­ры пре­ры­ва­ю­щей. Дли­тель­ность вы­пол­не­ния является главным недостатком программного решения, мо­ти­ви­ро­вав­шим разработку аппаратного.

Блок заканчивается инструкцией возврата из прерывания — IRET, при выполнении которой ресурсоемкую опе­­ра­­цию пе­ре­за­груз­ки контекста придется повторить в обратном порядке. А между этими действиями, уда­лен­ный про­цес­сор, за­пус­кая про­це­ду­ру обработки прерывания, очищает собственный TLB, например, ин­ст­рук­ци­ей INVLPG или пу­тем вы­ше опи­сан­ных ма­ни­пу­ля­ций с регистром CR3, и записывает в память ста­тус­ную информацию, подтверждающую вы­пол­не­ние.

О подсистеме APIC

Поскольку механизм RAR based TLB shootdowns основывается на расширении функциональности под­сис­те­мы APIC, ос­ве­жим в памяти ряд моментов.

Архитектура APIC (Advanced Programmable Interrupt Controller) лежащая в основе муль­ти­про­цес­сор­ной спе­ци­фи­ка­ции, разработана в конце прошлого века в качестве замены устаревшей модели обработки прерываний на ос­но­ве конт­рол­ле­ров Intel 8259. На тот момент требовалось мо­дер­ни­зи­ро­вать архитектуру с учетом по­яв­ле­ния муль­ти­про­цес­сор­ных систем. Были решены две задачи:

  1. Наряду с приоритетом обработки запросов на прерывание, определяющим последовательность об­слу­жи­ва­ния пе­ри­фе­рий­ных устройств, введено новое понятие «приоритет процессора». Уп­ро­щен­но говоря, при наличии не­сколь­ких CPU, необходимо обработку возникшего асинхронного со­бы­тия поручить тому процессору, который в дан­ный момент выполняет наименее приоритетную за­да­чу.
  2. Новой обязанностью подсистемы обработки прерываний стала организация передачи сообщений меж­ду про­цес­со­ра­ми, механизм получил название IPI (Inter-Processor Interrupts). При этом про­цес­сор-источник от­прав­ля­ет со­об­ще­ние цик­лом записи в регистр ICR (Interrupt Command Re­gist­er). Процессор-получатель вос­при­ни­ма­ет со­об­ще­ние в виде при­шед­ше­го запроса на пре­ры­ва­ние.

Модернизация подсистемы APIC
для поддержки RAR

Детализуем изменения, отраженные в документе «Remote Action Request White Paper», связанные с вне­д­ре­ни­ем фун­к­ци­о­наль­но­с­ти Remote Ac­tion Re­quest.

Обновленный регистр Interrupt Command Register контроллера Local APIC; ранее зарезервированный код 011b в поле Destination Mode (биты 10-8) задает новый тип сообщения RAR — Remote Action Request

Обновленный регистр Interrupt Command Register контроллера Local APIC; ранее зарезервированный код 011b в поле Destination Mode (биты 10-8) задает новый тип сообщения RAR — Remote Action Request

Как можно заметить, перечисление возможных значений поля Destination Mode (биты 10-8) до­пол­не­но ко­дом 011:RAR.

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

  1. виртуальное адресное пространство для приложений, обеспечиваемое ОС;
  2. виртуальное адресное пространство для гостевых ОС, обеспечиваемое гипервизором вир­ту­а­ли­за­ции.

Полный набор команд Remote Action Request, возможности которого выходят за рамки обсуждаемой темы син­хро­ни­за­ции TLB, можно найти в документе, ссылка на который приведена в начале раздела. Акцентируем, RAR bas­ed TLB shootdowns это лишь один из вариантов применения RAR.

  • Документ детализирует формат Model-Specific регистров (MSR), управляющих функ­ци­о­наль­но­стью RAR, а также двух видов таблиц в оперативной памяти.
  • Управляющая информация (Payload Table) формируется процессором, инициирующим запрос RAR и де­та­ли­зу­ет тип операции для выполнения процессором-получателем.
  • Статусная информация (Action Vector), формируется процессором-получателем и отражает ре­зуль­та­ты вы­пол­не­ния. Таким образом, процессор, инициировавший запрос, проверяет результат.

Аппаратное решение на основе
RAR based TLB shootdowns

Рассмотрим процедуру синхронизации TLB с применением RAR based TLB shootdowns.

Последовательность операций при аппаратной синхронизации TLB двух логических процессоров

Последовательность операций при аппаратной синхронизации TLB двух логических процессоров

Локальный процессор, выполнив обновление дескрипторов PTE (Page Table Entry), отправляет RAR-со­об­ще­ние уда­лен­но­му про­цес­со­ру. Очистка собственного TLB здесь может быть реализована уни­фи­ци­ро­ван­ным ме­то­дом — от­прав­кой со­об­ще­ния «са­мо­му се­бе». Затем локальный процессор ожидает за­вер­ше­ния опе­ра­ции на всех удаленных про­цес­со­рах, об этом сиг­на­ли­зи­ру­ют ап­па­рат­но устанавливаемые фла­ги.

Удаленный процессор, приняв запрос на вы­пол­не­ние инвалидами — Receive RAR signal, выполняет очистку TLB и ус­та­нов­ку ста­тус­ных пе­ре­мен­ных, индицирующих завершение. В отличие от ранее рассмотренного про­­г­рам­мно­го ре­ше­ния, дей­ст­вия вы­пол­ня­ют­ся ап­па­рат­но, минуя длинные последовательности входа в про­це­ду­ру об­ра­бот­ки пре­ры­ва­ния и вы­хо­да из нее. Для этого логика работы контроллера Local APIC должна быть расширена. Кон­т­рол­лер, за­фик­си­ро­вав вхо­дя­щее со­об­ще­ние RAR и определив его тип, генерирует сиг­нал очистки TLB, а также ини­ци­иру­ет об­нов­ле­ние ста­тус­ных по­лей в оперативной памяти.

Другим отличием является возможность выполнения RAR-запроса независимо от состояния флага раз­ре­ше­ния пре­ры­ва­ний (IF), а также при длительной обработке инструкций, когда обычный запрос на прерывание мо­жет быть вос­при­нят толь­ко по за­вер­ше­нии выполнения текущей инструкции. Включением данной опции управляет бит IGNORE_IF в регистре RAR_CONTROL MSR.

Резюме

Запуск и завершение, а также выделение и освобождение блоков памяти, в типовом случае составляют не­зна­чи­тель­ную часть времени работы приложения. Если объем обрабатываемых данных существенно пре­вос­хо­дит объ­ем фи­зи­че­ской памяти платформы, процесс обработки может сопровождаться довольно ин­тен­сив­ным своп­пин­гом. Чем мень­шие по­ка­за­те­ли ла­тент­но­сти обеспечивает mass-storage устройство, тем за­мет­нее интервал времени, за­тра­чи­ва­е­мый на программную синхронизацию TLB, что особенно значимо при ис­поль­зо­ва­нии скоростных Optane-устройств.

Осторожно предположим, что некоторые сценарии с интенсивным своп­пин­гом в конфигурациях с вы­со­ко­про­из­во­ди­тель­ны­ми NVMe-устройствами могут получить практически значимое ускорение при ап­па­рат­ной под­держ­ке син­хро­ни­за­ции TLB.

Вместо послесловия

Как можно заключить из комментариев Intel, технология Remote Action Request и один из основных сценариев ее при­ме­не­ния — RAR based TLB shootdowns на момент публикации этого материала все еще находятся на этапе тес­ти­ро­ва­ния и об­суж­де­ния, принять участие в котором корпорация предлагает всем за­ин­те­ре­со­ван­ным лицам. Ряд ар­хи­тек­тур­ных осо­бен­но­с­тей и само наличие этой технологии в процессорах Sapphire Rapids и последующих раз­ра­бот­ках Intel, на дан­ный момент остаются под вопросом.

Показательно, что в документации не указан конкретный бит CPUID, индицирующий поддержку фун­к­ци­о­наль­но­с­ти в при­выч­ном фор­ма­те, как элемент битовых полей CPUID features bitmap. Вместо этого, рекомендуется оп­ре­де­лить мо­дель про­цес­со­ра, срав­ни­вая CPUID-сигнатуру (параметры Family и Model) с заданными кон­стан­та­ми, а затем про­ве­рить пер­вый бит регистра IA32_CORE_CAPABILITIES MSR. Решение не иде­аль­ное, по­сколь­ку де­тек­ти­ро­ва­ние, тре­бу­ю­щее доступа к Model-Specific регистрам может быть выполнено толь­ко в про­це­ду­ре, имеющей при­ви­ле­гии ядра ОС. Для пользовательских приложений чтение MSR не­до­ступ­но.

Впрочем, досужий читатель может сказать, что это логично — изменение страничных таблиц и применение тех­но­ло­гии Re­mote Ac­tion Re­quest по определению возможно только в привилегированном коде ядра ОС. Тем не ме­нее, хо­те­лось бы пред­по­ло­жить, что в финальной редакции спецификации неудобство де­тек­ти­ро­ва­ния будет устранено и проверить наличие RAR based TLB shootdowns можно будет и в user mode с ис­поль­зо­ва­ни­ем CPUID features bitmaps. Это важ­но для кор­рект­ной ра­бо­ты ин­фор­ма­ци­он­но-ди­аг­но­сти­че­ских ути­лит, не располагающих kernel mode драйвером.