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

Для обычных хранилищ в памяти WB, которые находятся в пределах той же строки кэша: да, порядок сохранения соответствует глобальному порядку наблюдаемости x86-TSO, см. Является ли 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 по тому же адресу выполнит обратную запись версии строки, содержащей эти данные хранилища. В противном случае он может выполнить обратную запись копии строки, в то время как последнее хранилище все еще находится в буфере хранилища или даже не выполняется. Это не означает, что вся обратная запись должна быть завершена перед любым последующим сохранением!

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

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