Может ли каждый кеш (L1, L2, LL C) работать либо в режиме обратной записи, либо в режиме сквозной записи?
В большинстве микроархитектур x86, да, все данные Унифицированные / кэши (способны) выполнять обратную запись и используются в этом режиме для всех обычных DRAM. Какой метод отображения кэша используется в процессоре Intel Core i7? содержит некоторые подробности и ссылки. Если не указано иное, по умолчанию все, кто говорит о x86, предполагают, что страницы DRAM будут иметь формат WB.
AMD Bulldozer сделала нетрадиционный выбор - использовать сквозную запись L1d с небольшим буфером 4k, сочетающим запись между это и L2. (https://www.realworldtech.com/bulldozer/8/). У этого есть много недостатков, и я думаю, что многие считают (оглядываясь назад) одной из нескольких слабостей или даже ошибок проектирования семейства Bulldozer (которые AMD исправила для Zen). Также обратите внимание, что Bulldozer был экспериментом в CMT вместо SMT (два ядра со слабым целым числом, совместно использующие блок FPU / SIMD, каждое с отдельными кэшами L1d, совместно использующими кэш L2) https://www.realworldtech.com/bulldozer/3/ показывает архитектуру системы.
Но, конечно, кэши бульдозеров L2 и L3 все еще были WB, архитекторы не были безумны. Кэширование ББ необходимо для снижения требований к пропускной способности для общего LL C и памяти . И даже L1d сквозной записи нуждался в буфере объединения записи, чтобы кэш L2 мог быть больше и медленнее, таким образом, служа своей цели иногда поражать, когда L1d пропускает. См. Также Почему размер кэша L1 меньше размера кэша L2 в большинстве процессоров?
Кэширование с сквозной записью может упростить конструкцию (особенно одноядерной системы). ), но в целом процессоры вышли за пределы этих десятилетий go. ( Обратная запись против сквозного кэширования? ). IIR C, некоторые рабочие нагрузки без использования ЦП иногда выигрывают от кэширования сквозной записи, особенно без записи-выделения, поэтому записи не загрязняют кэш. В x86 есть хранилища NT, чтобы избежать этой проблемы.
Так что, если для атрибута страницы задано значение сквозной записи, то все они будут сквозными?
Да, каждый магазин должен go вплоть до DRAM на странице, помеченной как WT.
Кеши оптимизированы для WB, потому что это то, что все используют, но, очевидно, поддерживают передачу на линию к внешним кешам без удаления от L1d. (Таким образом, WT не превращает хранилища во что-то вроде movntps обхода / удаления хранилищ кэша.)
Когда страница должна быть настроена на сквозную запись? Каковы преимущества этого?
В основном никогда; (почти?) все рабочие нагрузки процессора лучше всего работают с WB-памятью.
ОС даже не удосужились упростить (или возможно?) для пространства пользователя выделение W C или WT DRAM страницы. (Хотя это, безусловно, не доказывает, что они никогда полезны.) Например, при ингибировании кэша ЦП я обнаружил ссылку о патче Linux, который никогда не входил в основное ядро, которое добавляло возможность отображения страницы WT.
WB, W C и U C являются общими для обычных DRAM, памяти устройства (особенно GPU) и MMIO соответственно.
Я видел по крайней мере одну бумагу, которая сравнивала WT с WB с U C с W C для некоторой рабочей нагрузки (гуглил, но не нашел, извините). И люди, тестирующие непонятные вещи x86, иногда включают его для полноты картины. например, Микроархитектура позади Meltdown - хорошая статья в целом (и связанная с тем, что вы читаете).
Одним из немногих преимуществ WT является то, что магазины заканчиваются в L3 быстро, где могут ударить нагрузки с других ядер. Это может стоить дополнительных затрат для каждого магазина на эту страницу, особенно если вы осторожны, чтобы вручную объединить свои записи в одно большое 32-байтовое хранилище AVX. (Или 64-байтовую запись полной строки AVX512.) И, конечно, используйте эту страницу только для общих данных.
Я не видел, чтобы кто-нибудь когда-либо рекомендовал делать это, и я не пытался это сделать , Возможно, потому что дополнительная пропускная способность DRAM для записи через L3 также не стоит выгоды для большинства случаев использования. Но, вероятно, также потому, что вам, возможно, придется написать модуль ядра, чтобы отобразить страницу таким образом.