clwb+sfence, можем ли мы удалить sfence, если записи выровнены по строке кэша?

Question

Согласно информации о заказе clwb (ссылка),

« Команда CLWB упорядочивается только операциями по ограничению хранилища. Например, программное обеспечение может использовать инструкции с префиксом SFENCE, MFENCE, XCHG или LOCK, чтобы гарантировать, что предыдущие хранилища включены в обратную запись. Инструкцию CLWB не нужно упорядочивать другая инструкция CLWB или CLFLUSHOPT. CLWB неявно упорядочивается с более старыми хранилищами, выполняемыми логическим процессором по тому же адресу ".

Если набор операций на Intel X86-64 выглядит следующим образом, могу ли я удалить « sfence » и по-прежнему гарантировать правильность, если записи (A) и запись (B) выровнены по строке кэша .

Я спрашиваю об этом, поскольку в Intel запись (A) и запись (B) упорядочены (TSO), а запись (A)->clwb(A) и запись (B)->clwb(B) упорядочены в соответствии с приведенным выше описанием. из clwb

      write(A)
clwb(A)
sfence()
write(B)
clwb(B)

Я делаю следующие предположения

1. компилятор не меняет порядок этих операций
2. Инструкция clwb () записывает грязную строку обратно в постоянный домен, поэтому пара write(A)->clwb(A) гарантирует, что измененное значение A находится в постоянном домене

Скажите, может ли удаление sfence нарушить правильность? если да, то по каким сценариям Спасибо

Answer 1

Для обычных магазинов в память WB, которые и в том же строке кэша: да сохранение порядок соответствует x86-TSO порядка глобального наблюдаемости см Is clflush или clflushopt когда авария атомной системы?. В противном случае это не гарантируется.

Кажется, вы имеете в виду, что A полностью содержится в одной строке кеша, а B - в отдельной.

Без SFENCE после аварии можно было бы увидеть эффект B, но не A. clwbне заказывается, поэтому последний может сначала сделать свой магазин постоянным. Это то, на что указывает руководство clwb, что в clwb отсутствует порядок написания. нормальные магазины.

Таким образом, согласно TSO запись (B) произошла, означает, что запись (A) произошла (возможно, она находится в буфере хранилища).

Нет, упорядочение x86-TSO касается порядка фиксации из буфера хранилища в L1d, указатель глобальной наблюдаемости. Это, конечно, полностью отделено от возможной обратной записи (через вытеснение или clwb) в DRAM. Операторы хранилища могут выполняться (записывать свой адрес + данные в буфер хранилища) в любом порядке, но не могут выполнять фиксацию до выхода из эксплуатации (т.е. когда они не являются спекулятивными). Кроме того, эта фиксация ограничена программным порядком, т.е. записи буфера хранилища порядка были выделены во время выдачи / переименования / выделения.

означает, что запись (A)-> запись (B) упорядочена, а запись (B)->clwb(B) упорядочена, так как clwb(B) может обойти запись (B) [таким образом нарушая ограничение порядка, установленное вручную], и произойти перед clwb(A), таким образом вызывая эффект clwb(B), видимый после сбоя, а не clwb(A)?

Нет, правило « неявно упорядочено со старыми магазинами ... по тому же адресу » гарантирует только то, что store + clwb по тому же адресу выполнит обратную запись версии строки, которая включает эти данные store. В противном случае он может выполнить обратную запись копии строки, в то время как последнее хранилище все еще находится в буфере хранилища или даже не выполняется. Это не означает, что вся обратная запись должна быть завершена перед последующим сохранением!

Порядок операций, при которых после сбоя появляется B, но не отображается A, следующий:

• A и B выполняются в некотором порядке
• A и B фиксируются в кэше L1d, когда это ядро ​​получает эксклюзивное право собственности MESI на их соответствующие строки, становясь глобально видимыми для других ядер.
• Инструкции clwb выполняются в какой-то момент, запрашивая, чтобы строки кэша были записаны обратно в DRAM в какой-то момент после фиксации хранилища.
• обратная запись строки A начинается в какой-то момент после того, как она фиксируется в L1d, и то же самое для строки B. Они могут начинаться в любом порядке, поскольку порядок clwb не гарантируется. другие операции clwb с другими строками, хотя на практике они, вероятно, запускаются в программе oder.
• clwb-B становится стойким
• машина теряет мощность до того, как clwb-A в полете переходит в область постоянства. Вы не запрашивали, чтобы операции clwb были упорядочены. друг друга, так что это разрешено.

Что касается переупорядочивания asm-инструкций, допускается следующий переупорядочение:

       store A
 store B
 clwb  B
 clwb  A     ; not ordered wrt. store B or clwb B

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

Я думаю, что главное, что вам не хватает, - это то, что clwb A - это отдельная операция от store A, она не привязана к ней. Это clwb будет позволено «случиться» после того, как другие , более поздние магазинах. магазин B находится по другому адресу, поэтому clwb не заказывается.

SFENCE может предотвратить это.