кеш - сброс и аннулирование операции - PullRequest
16 голосов
/ 22 февраля 2010

У меня есть вопросы по синхронизации кеша.

Invalidate : перед тем, как процессор попытается прочитать часть памяти, обновленную устройством, соответствующая память должна быть аннулирована.

Сброс : перед тем, как устройство прочитает часть памяти, обновленную ЦП, ЦП должен сбросить (запись также правильна?) Содержимое из кэша в память, чтобы устройство считывало содержимое из памяти обновленное содержание.

Если сброс не выполняется, он может считывать ненужные данные, присутствующие в памяти, так как память все еще не обновляется содержимым, записанным в кэш.

Пожалуйста, подтвердите правильность моего понимания?

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

Нужно ли нам следовать последовательности, такой как flush, за которой следует инвалид?

Есть ли сценарий, в котором будет полезен аннулирование с последующим сбросом?

Ответы [ 2 ]

26 голосов
/ 27 февраля 2010

Flush действительно записывает содержимое кеша в основную память, а при аннулировании помечает строки кеша как недействительные, поэтому последующие чтения идут в основную память.

Я думаю, что вы бы объединили сброс и аннулирование, если бы устройство обновляло блок памяти: очистка гарантировала бы, что на устройстве было самое последнее содержимое, а аннулировал бы то, что когда устройство завершит работу, процессор прочитает новое содержимое из памяти.

3 голосов
/ 20 февраля 2017

Пожалуйста, подтвердите правильность моего понимания?

Обычно вы абсолютно правы, но есть камни, которые могут споткнуться. Вы не указали платформу HW. Если мы не говорим о маленьких встроенных контроллерах, упакованных с SRAM, рассмотрим следующее. Процессоры с MMU поддерживают различные атрибуты памяти для обычной памяти DDR и памяти драйверов (HW). Последний не кешируется, поэтому нет проблем с очисткой / аннулированием.


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

Поскольку в тегах упоминается DMA, существует несколько сценариев (при условии, что буфер HW является не кешируемой памятью устройства):

  1. Передача данных DMA из памяти DDR в буфер HW.
  2. Передача данных DMA из буфера HW в DDR (HW получила данные и хочет сделать их доступными для CPU)
  3. Передача DMA из DDR в другой регион DDR.


  1. Буфер DDR должен быть очищен перед DMA. Буфер драйвера не кешируется, поэтому нет необходимости в его аннулировании.
  2. Буфер DDR должен быть признан недействительным до или после (подробнее см. NOTE ниже) Передача DMA для предотвращения использования ЦП «старых» данных из кэша Очистка буфера HW избыточна.
  3. Буфер 'Source' должен быть очищен, буфер 'Destination' должен быть признан недействительным. Таким образом, действительные данные находятся в памяти для DMA перед передачей, и CPU не берет «грязь» из кэша после того, как DMA сделал свою работу.


NOTE: Очевидно, что «источник» должен быть очищен перед DMAing. Еще есть вопрос, когда сделать недействительным . Технически это происходит до того, как CPU попытается получить доступ к данным «Destination», и может быть до или после DMA (мы должны убедиться, что DMA завершил работу). Аннулирование IRL после DMAing может привести к проблеме. Ссылаться на Сбросить / Неправильный диапазон по виртуальному адресу; ARMv8; Cache;

Как вы могли видеть аннулирование для этой конкретной платформы должно быть сделано до DMAing. Также несуразный код BSP для устройства ARMv7 Я нашел рекомендацию сделать недействительным буфер назначения до передачи DMA.


Нужно ли следовать последовательности, такой как flush, за которой следует инвалид?

Предполагая, что исходный и целевой буферы не пересекаются, нет никаких зависимостей. Вы могли бы flush-invalidate или invalidate-flush.


Есть ли сценарий, в котором будет полезен аннулирование с последующим сбросом?

Не думаю.

...