Будет ли CPUID сериализировать спекулятивное кеширование данных? - PullRequest
0 голосов
/ 15 января 2019

Я нашел описание спекулятивной процедуры кэширования данных из нескольких записей инструкций в Intel Vol.2.

Например, lfence:

Процессоры могут свободно извлекать и кешировать данные спекулятивно из регионов системной памяти, использующей типы памяти WB, WC и WT. это спекулятивное извлечение может происходить в любое время и не связано с выполнение инструкции. Таким образом, он не упорядочен в отношении выполнение инструкции LFENCE; данные могут быть внесены в кеширует спекулятивно непосредственно перед, во время или после выполнения Инструкция LFENCE.

Кроме того, я обнаружил на онлайн-ресурсах, что спекулятивное кэширование также перемещает данные из более дальнего кеша в более близкий.

Я хочу знать, сможет ли самая сильная инструкция сериализации CPUID предотвратить спекулятивное кэширование через барьер.

Я уже искал запись CPUID в Intel Vol.2 и раздел «Инструкция по сериализации» в Intel Vol.3. Но это ничего не говорит о спекулятивном кешировании данных.

1 Ответ

0 голосов
/ 15 января 2019

LFENCE уже достаточно силен (по крайней мере, на практике), чтобы не дать ЦП фактически просматривать инструкции по загрузке после него, но ЦП может свободно умозрительно загружаться по другим причинам.

Остановка, которая потребует какого-то заглядывания за барьер, чтобы выяснить, для каких адресов отключить предварительную выборку HW. Это совсем не практично. CPUID или другие инструкции по сериализации не более сильны, чем LFENCE, для остановки предварительных загрузок.

ЦП всегда разрешен для умозрительного извлечения из памяти в областях WB и WT / страницах . Руководство по оптимизации Intel документирует некоторые сведения об аппаратных средствах предварительной выборки в некоторых из их моделей ЦП, поэтому на практике вы можете избежать действий до CPUID, которые могут вызвать такие предварительные выборки.

(WC является слабо упорядоченным не кэшируемым + комбинированием записи, но спекулятивная выборка также допускается там на бумаге. В реальной жизни это, вероятно, происходит только в тени ошибочного прогнозирования ветви, а не предварительной выборки HW. Обычно она не кэшируется, как WB и WT.)


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


Возможно, теоретически вы могли бы иметь процессор x86, который смотрел бы вперед в потоке команд для инструкций загрузки / сохранения и умозрительно предварительно выбирал их, отдельно от фактического выполнения их (которое определение LFENCE Intel блокировало бы) , Я не думаю, что что-нибудь помешает этому сделать это через CPUID.

Вероятно, никто не будет проектировать такой процессор, потому что

  1. Это не стоит транзисторов / мощности. Начать предварительную выборку, как только к ней может приступить обычное внеплановое выполнение, уже достаточно. И кроме абсолютных / RIP-относительных адресов или прямых переходов, вам понадобится зарегистрировать значения из ядра OoO, чтобы получить полезный адрес предварительной выборки.
  2. Взгляд в прошлое LFENCE / CPUID является извращенным; они достаточно редки, чтобы победить спекулятивное «выполнение» нагрузок за ними, что является частью эпохи Призрака.
...